- Pacman-dev - lists.archlinux.org

[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

[pacman-dev] CVS update of pacman-lib (17 files)
by Dan McGee 18 Jun '07

18 Jun '07

Date: Sunday, June 17, 2007 @ 20:15:37 Author: dan Path: /home/cvs-pacman/pacman-lib Modified: NEWS (1.15 -> 1.16) configure.ac (1.41 -> 1.42) etc/makepkg.conf.in (1.17 -> 1.18) etc/pacman.d/mirrorlist.in (1.11 -> 1.12) lib/libalpm/po/de.po (1.20 -> 1.21) lib/libalpm/po/en_GB.po (1.6 -> 1.7) lib/libalpm/po/es.po (1.2 -> 1.3) lib/libalpm/po/fr.po (1.13 -> 1.14) lib/libalpm/po/hu.po (1.13 -> 1.14) lib/libalpm/po/it.po (1.23 -> 1.24) lib/libalpm/po/libalpm.pot (1.11 -> 1.12) lib/libalpm/po/pl_PL.po (1.2 -> 1.3) lib/libalpm/po/pt_BR.po (1.12 -> 1.13) lib/libalpm/po/ru_RU.po (1.4 -> 1.5) scripts/repo-add (1.10 -> 1.11) src/pacman/po/de.po (1.24 -> 1.25) src/pacman/po/pl_PL.po (1.2 -> 1.3) Check in changes for 3.0.5 release (mostly backports) * Update the mirrorlist * Fix FS7338- the previous repo-add fix didn't quite do the job, but it should be fixed now. * Small updates to translations files * Add -mtune=generic to default CFLAGS (req'd by GCC 4.2) ----------------------------+ NEWS | 6 +++++ configure.ac | 2 - etc/makepkg.conf.in | 4 +-- etc/pacman.d/mirrorlist.in | 8 +++++++ lib/libalpm/po/de.po | 26 +++++++++++----------- lib/libalpm/po/en_GB.po | 26 +++++++++++----------- lib/libalpm/po/es.po | 26 +++++++++++----------- lib/libalpm/po/fr.po | 26 +++++++++++----------- lib/libalpm/po/hu.po | 26 +++++++++++----------- lib/libalpm/po/it.po | 26 +++++++++++----------- lib/libalpm/po/libalpm.pot | 26 +++++++++++----------- lib/libalpm/po/pl_PL.po | 34 ++++++++++++++--------------- lib/libalpm/po/pt_BR.po | 26 +++++++++++----------- lib/libalpm/po/ru_RU.po | 26 +++++++++++----------- scripts/repo-add | 2 - src/pacman/po/de.po | 49 ++++++++++++++++++++++++++++--------------- src/pacman/po/pl_PL.po | 10 ++++---- 17 files changed, 189 insertions(+), 160 deletions(-) The diff is longer than the limit of 39KB.

1 0

Re: [pacman-dev] How does pacman interact with a package's INSTALL script
by Andrew Fyfe 17 Jun '07

17 Jun '07

lordbad wrote: > In the documentation I have read the following: > > There are also install files. This PKGBUILD specifies 'foo.install' as the > package's install file. Here is an example install file: > > post_install() { > /bin/true > } > > post_upgrade() { > /bin/true > } > > pre_remove() { > /bin/true > } > > op=$1 > shift > > $op "$@" > > Here are the function explainations : > > * post_install : this script is run right after files are installed, it > takes one argument : > o the package version > * post_upgrade : this script is run after all files have been upgraded, > it takes two arguments : > o the new package version > o the old package version > * pre_remove : this script is run right before files are removed (stop a > daemon for example) and takes one argument : > o the package version > > The three lines at the bottom are needed in every install file so that they > run properly. > > But I do not understand how does pacman handle these scripts. Does it source the > scripts first and then call the shell functions defined in them with some C > function like "system" for example? But if it does so why are the last 3 lines > needed - I see little if any need for them. So if anyone can give me some hints > on the subject and maybe even mention which of pacman's source files implements > this functionality I'd be very grateful. Thanks in advance for your help. > > Best Regards, > Bozhidar > > > _____________________ > http://www.e-card.bg/ > > > _______________________________________________ > pacman-dev mailing list > pacman-dev(a)archlinux.org > http://archlinux.org/mailman/listinfo/pacman-dev The function your looking for is _alpm_runscriptlet() (lib/libalpm/trans.c:567) http://projects.archlinux.org/git/?p=pacman.git;a=blob;f=lib/libalpm/trans.… Pacman runs 'source <path to file>/.INSTALL <function name> <old ver> <new ver>', the last 3 lines of .INSTALL are needed to get the function name and call it. Andrew

4 6