- Pacman-dev - lists.archlinux.org

[pacman-dev] CVS update of pacman-lib/lib/libalpm (add.c)
by Dan McGee 20 Jun '07

20 Jun '07

Date: Wednesday, June 20, 2007 @ 17:52:24 Author: dan Path: /home/cvs-pacman/pacman-lib/lib/libalpm Modified: add.c (1.132 -> 1.133) Revert erroneous chmod 'fix'. -------+ add.c | 2 -- 1 file changed, 2 deletions(-) Index: pacman-lib/lib/libalpm/add.c diff -u pacman-lib/lib/libalpm/add.c:1.132 pacman-lib/lib/libalpm/add.c:1.133 --- pacman-lib/lib/libalpm/add.c:1.132 Thu May 17 23:26:24 2007 +++ pacman-lib/lib/libalpm/add.c Wed Jun 20 17:52:24 2007 @@ -704,8 +704,6 @@ _alpm_log(PM_LOG_ERROR, _("could not extract %s (%s)"), filename, strerror(errno)); alpm_logaction(_("error: could not extract %s (%s)"), filename, strerror(errno)); errors++; - } else { - chmod(filename, archive_entry_mode(entry)); } /* calculate an hash if this is in newpkg's backup */

1 0

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-236-gf372a54
by Dan McGee 20 Jun '07

20 Jun '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via f372a542b9f37b7e36cc3419bf14b5c4e8fbb94c (commit) from cacf968970bbc63e8eb519e40194e6c083ba6a06 (commit) - Log ----------------------------------------------------------------- commit f372a542b9f37b7e36cc3419bf14b5c4e8fbb94c Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jun 20 17:38:56 2007 -0400 Revert "Fix libarchive permission extraction" This was a bad way to fix a problem upstream. Doing this resulted in symlink permissions being applied to files installed on the system, leaving some binaries with 77 permission, etc. This reverts commit 4e6b7c1cde4c0ac1d035b51f9af19510a7c9135e. ----------------------------------------------------------------------- Diffstat: lib/libalpm/add.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ cacf968970bbc63e8eb519e40194e6c083ba6a06 \ f372a542b9f37b7e36cc3419bf14b5c4e8fbb94c

1 0

[pacman-dev] pacman screws up permissions
by Thomas Bächler 20 Jun '07

20 Jun '07

I just installed the ntfs-3g package with pacman 3.0.5-1: $ /bin/ls -lhF /bin/ntfs-3g /usr/man/man8/ntfs-3g.8.gz -rwxrwxrwx 1 root root 36K 20. Jun 01:45 /bin/ntfs-3g* -rwxrwxrwx 1 root root 3,0K 20. Jun 01:44 /usr/man/man8/ntfs-3g.8.gz* The permissions in the tarfile are 755 for /bin/ntfs-3g (and I suppose they are 644 for the manpage, didn't check that). This behaviour can cause critical bugs and in this case is security-relevant, as a user could change the ntfs-3g binary, which is executed at boot time on many systems. This has to be fixed FAST.

2 2

[pacman-dev] libarchive, pacman, and libtool-slaying
by Dan McGee 19 Jun '07

19 Jun '07

I'm sending this to two lists to see who can offer some insight, as I tried and failed earlier to get pacman to correctly build with a newer version of libarchive. I think it may deal with having la files in the package, but I am not sure so I'll outline what I've tried and know so far. Libarchive website: http://people.freebsd.org/~kientzle/libarchive/ Current version: 2.2.3 Current Arch Linux version: 1.3.1-2 As you can see, we are a ways behind. I up-ed the PKGBUILD for libarchive, rebuilt it without problems (as far as I can tell), and then pacman -U <new libarchive> and tried to compile pacman. The ldd output showed that it correctly linked against the new libarchive.so.2, but it had somehow also linked against libarchive.so.1. I tried rebuilding libarchive using options=(!libtool), but that didn't seem to fix anything- it actually just spit some more errors saying libarchive was missing la files and such. OK, long explanation, but it comes down to this: 1. How can we get pacman to compile with libarchive without needing the la files? libdownload seems to work fine without them, etc. 2. Where is this mysterious link to libarchive.so.1 coming from when it isn't even present on my system anymore? This applies to both the most recent CVS release and our GIT tree at projects.al.org. -Dan

2 1

[pacman-dev] [patch] alpm_removedeps bug+fix && alpm_depcmp-discussion
by ngaba＠petra.hos.u-szeged.hu 19 Jun '07

19 Jun '07

Hi! I attached the pactest file and my patch. I also made some modifications in alpm_removedeps' args, because the old one was a bit messy for me. And I think that my version is faster. can_remove_package is a bit stupid (compared to alpm_checkdeps), but I leave it untouched, because speed is more important here than "perfection". As you see, this patch contains my usual "for (pkg in pkgcache) if(alpm_depcmp(pkg, depend))..." stuff. We should discuss something now: This method has a drawback sometimes in speed: This method implicitly reads the pkgcache with full pkginfo, because alpm_depcmp needs provisions. If we've already done this (or we need to do this later) or we must collect ALL dependency satisfier in pkgcache this is not a problem. However, for example if we just want to know if there is ANY package in pkgcache which satisfies a dependency (something similar to can_remove_package without using requiredby fields), then FIRST check for package names THEN for providers is probably faster, if the pkgcache is loaded with pkgname-pkgver info only: because we have great chance to find a satisfier pkgname-pkgver pair and we can stop, we can answer the question without reading the ugly PKGINFO files for providers. Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 10

[pacman-dev] FS7461: Pacman permission problems
by Andrew Fyfe 19 Jun '07

19 Jun '07

There's still some problems (FS7461) with pacman/libarchive and setuid files, the permissions are getting screwed up when extracting the file. The best fix I can see is to upgrade to libarchive-2.2.3 and remove the chmod hack Aaron added to lib/libalpm/add.c

1 0

[pacman-dev] installing two packages conflicting with each other
by Xavier 19 Jun '07

19 Jun '07

http://bugs.archlinux.org/task/7415#comment17206 I think this bug is not so obvious, there are two package in the same group, one conflicts / replaces / provides the other. There are at least 3 cases to consider here for the state before the installation : none of the packages are installed, old package is installed, new package is installed. Should pacman always choose the package replacing the other ? And what should happen without the replace flag, if the package only provides and conflicts with the other ?

1 2

Re: [pacman-dev] libalpm issues (was: alpm_removedeps bug+fix && alpm_depcmp-discussion)
by Dan McGee 19 Jun '07

19 Jun '07

On 6/18/07, Xavier <shiningxc(a)gmail.com> wrote: > 2007/6/18, Dan McGee <dpmcgee(a)gmail.com>: > > On 6/18/07, ngaba(a)petra.hos.u-szeged.hu <ngaba(a)petra.hos.u-szeged.hu> wrote: > > > Hi! > > > > > > I attached the pactest file and my patch. I also made some > > > modifications in alpm_removedeps' args, because the old one was a bit > > > messy for me. And I think that my version is faster. > > > > > > can_remove_package is a bit stupid (compared to alpm_checkdeps), but I > > > leave it untouched, because speed is more important here than > > > "perfection". > > > > IMO, doing things right is what we want to do in 99% of the cases this > > speed vs. perfection issue comes up, so I'm going to disagree with you > > here. > > > > It looks like checkdeps could indeed be used here. > There is also the install reason which comes into play here though. > This problem was mentioned here : > http://bugs.archlinux.org/task/3241 > > Aaron didn't see any reason for checking that the packages removed by > -Rs are only dependencies, but I believe there is one, as I tried to > explain in my comment. > > > In addition, to assume anything only makes an ass out of u (you) and > > me. I don't want to introduce any functions that depend on a > > particular quirk of our list implementation, especially since this is > > one of the things we have considered changing. > > > > What about just renaming alpm_list_add to alpm_list_add_last ? > That way, there isn't any assumption, it's explicit :) This isn't a bad idea, but I'm thinking of changes on a much larger scale. Read here for details: http://isis.poly.edu/kulesh/stuff/src/klist/ > > I feel that if we look at the bigger picture and stop thinking of add, > > remove, and sync as isolated actions, then we could get some HUGE > > refactoring and code reduction going on with cases like this. However, > > this will be one large undertaking. > > > > There are often several ways to do things right, and we probably don't > all see the same, so it would help if it was a bit more concrete :) > You are probably the only one who can get things exactly like you > want, unless maybe you explain it in details. I agree- and part of this is me NOT trying to enforce my 'right' way on everyone else. Here is how I see our operations-based thinking being reformed a bit. There are two baseline operations- install (add) and remove. upgrade is a combination of an add and remove, and sync is a combination of install, remove, upgrade, and a little extra sugar on the side. Instead of having duplicated code everywhere, we should be able to build up a set of functions that are used by the base operations, then use these base operations to build an upgrade, then use those to build a sync. By the time we get to a sync operation, we really shouldn't have much left to code at a low level, unlike the current code base. -Dan

2 1

[pacman-dev] turkish locale problem, bug left in pacman 3.0 branch
by Xavier 19 Jun '07

19 Jun '07

http://bugs.archlinux.org/task/7235?histring=turkish http://bbs.archlinux.org/viewtopic.php?id=34301 Maybe this should be fixed there too ?

2 1

[pacman-dev] [patch] I. deps.c/checkdeps bugfix + upgrade059.py
by Nagy Gabor 18 Jun '07

18 Jun '07

Hi! I started to work on deps.c. I send smaller patches instead of a big one. At first I rewrite alpm_*deps functions (implement topological sort...); I merge them later (which would be the most optimal imho) after testing. I found a bug: ---upgrade059.py--- self.description = "Try to upgrade packages which would break a multiple-depend" lp1 = pmpkg("pkg1") lp1.depends = ["imaginary"] self.addpkg2db("local", lp1) lp2 = pmpkg("pkg2", "1.0-1") lp2.provides = ["imaginary"] lp2.requiredby = [ "pkg1" ] self.addpkg2db("local", lp2) lp3 = pmpkg("pkg3", "1.0-1") lp3.provides = ["imaginary"] lp3.requiredby = [ "pkg1" ] self.addpkg2db("local", lp3) p2 = pmpkg("pkg2", "1.0-2") self.addpkg(p2) p3 = pmpkg("pkg3", "1.0-2") self.addpkg(p3) self.args = "-U %s" % " ".join([p.filename() for p in p2, p3]) self.addrule("PACMAN_RETCODE=1") self.addrule("PKG_EXIST=pkg1") self.addrule("PKG_VERSION=pkg2|1.0-1") self.addrule("PKG_VERSION=pkg3|1.0-1") ------------------- Here is my patch (WARNING: with large targetlist this may cause notable slowdown). ------------------- diff -Naur pacman-lib/lib/libalpm/deps.c pacman-lib.new/lib/libalpm/deps.c --- pacman-lib/lib/libalpm/deps.c 2007-03-19 05:23:45.000000000 +0100 +++ pacman-lib.new/lib/libalpm/deps.c 2007-04-21 16:42:29.000000000 +0200 @@ -271,8 +271,9 @@ for(l = _alpm_db_get_pkgcache(db); l; l = l->next) { pmpkg_t *pkg = l->data; - if(strcmp(alpm_pkg_get_name(pkg), alpm_pkg_get_name(oldpkg)) == 0) { - /* well, we know this one succeeds, but we're removing it... skip it */ + if(_alpm_pkg_find(alpm_pkg_get_name(pkg), packages)) { + /* we ignore packages that will be updated because we know that + updated ones don't satisfy depend.*/ continue; } ------------------ Bye, ngaba

6 32