- Pacman-dev - lists.archlinux.org

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-242-g0e4c1e8
by Dan McGee 26 Jun '07

26 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 0e4c1e86ed16c4793b9521e8152b30cc166aae68 (commit) via 7653bb93997f52848b54ab80868cd6da52808a75 (commit) from da66bedf4f98897dfc350195314089028050fa7d (commit) - Log ----------------------------------------------------------------- commit 0e4c1e86ed16c4793b9521e8152b30cc166aae68 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Tue Jun 26 12:00:22 2007 -0400 Add sync301 pactest- pacman gains new deps and should be pulled in Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 7653bb93997f52848b54ab80868cd6da52808a75 Author: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Date: Mon Jun 18 10:32:38 2007 -0400 Make alpm_splitdep immutable The alpm_splitdep function formerly overwrote the input string, causing a few issues. Fix this. Signed-off-by: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: lib/libalpm/deps.c | 14 +++++++++----- pactest/tests/sync301.py | 25 +++++++++++++++++++++++++ 2 files changed, 34 insertions(+), 5 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ da66bedf4f98897dfc350195314089028050fa7d \ 0e4c1e86ed16c4793b9521e8152b30cc166aae68

1 0

[pacman-dev] [patch] alpm_splitdep overwrites input string
by ngaba＠petra.hos.u-szeged.hu 26 Jun '07

26 Jun '07

Hi! I told everything in the subject, patch attached. This also fixes sync300.py Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 6

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-240-gda66bed
by Dan McGee 26 Jun '07

26 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 da66bedf4f98897dfc350195314089028050fa7d (commit) via 2ae043866045bbeef129a4b503ee1f5486545821 (commit) via f401e523981a72664d7f52e5697e3e09de597aeb (commit) from 0de5c97193f16195351957eada94f3e39a2d7d05 (commit) - Log ----------------------------------------------------------------- commit da66bedf4f98897dfc350195314089028050fa7d Author: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Date: Mon Jun 18 10:40:23 2007 -0400 Remove unnecessary trans parameter from _alpm_checkdeps The trans parameter was never used, so remove it. Signed-off-by: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 2ae043866045bbeef129a4b503ee1f5486545821 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Jun 17 23:40:21 2007 -0400 Don't extract any top-level files in a package that start with '.' For future possibilities, don't extract any files that start with '.'. This will allow us to add features such as the ChangeLog viewing without having to wait to include these files in packages, because older versions of pacman will be forward compatable with 'hidden' files at the root level of the package. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit f401e523981a72664d7f52e5697e3e09de597aeb Author: Dan McGee <dan(a)archlinux.org> Date: Sun Jun 17 20:34:09 2007 -0400 Mirror update and NEWS updates Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: NEWS | 8 ++++++++ etc/pacman.d/mirrorlist.in | 5 +++++ lib/libalpm/add.c | 11 +++++++++-- lib/libalpm/deps.c | 5 ++--- lib/libalpm/deps.h | 2 +- lib/libalpm/remove.c | 4 ++-- lib/libalpm/sync.c | 4 ++-- 7 files changed, 29 insertions(+), 10 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 0de5c97193f16195351957eada94f3e39a2d7d05 \ da66bedf4f98897dfc350195314089028050fa7d

1 0

[pacman-dev] [alpm] PM_ERR_PKG_HOLD - what's this?
by Georg Grabler 21 Jun '07

21 Jun '07

Hello guys, With the current ALPM version i get PM_ERR_PKG_HOLD on adding packages. In the current pacman GIT i could just find it in the remove process. Anyway, what does it mean? Has something changed so i need to define holdpkgs in some way? Is there even a need to define them? Hasn't been some weeks ago, so something must have been changed. Yours, Georg (STiAT)

2 4

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-237-g0de5c97
by Dan McGee 21 Jun '07

21 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 0de5c97193f16195351957eada94f3e39a2d7d05 (commit) from f372a542b9f37b7e36cc3419bf14b5c4e8fbb94c (commit) - Log ----------------------------------------------------------------- commit 0de5c97193f16195351957eada94f3e39a2d7d05 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jun 20 17:54:42 2007 -0400 libalpm/util.c: remove unnecessary include Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: lib/libalpm/util.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ f372a542b9f37b7e36cc3419bf14b5c4e8fbb94c \ 0de5c97193f16195351957eada94f3e39a2d7d05

1 0

[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

[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

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-235-gcacf968
by Dan McGee 17 Jun '07

17 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 cacf968970bbc63e8eb519e40194e6c083ba6a06 (commit) via 2ab320a3885226ce28da0f2f2bc84b5f2d0f0539 (commit) via 520841ee8a82460e0abb2a9a44c857556604cf56 (commit) via a486fec3c48d57d48c7d871161c1510be10e0924 (commit) from 7bd4486ebd15ba9cca0ee3e6a2c2ddc88ff104dc (commit) - Log ----------------------------------------------------------------- commit cacf968970bbc63e8eb519e40194e6c083ba6a06 Author: Dan McGee <dan(a)archlinux.org> Date: Thu Jun 14 11:12:21 2007 -0400 Update Doxyfile and add a few missing parts of documentation Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 2ab320a3885226ce28da0f2f2bc84b5f2d0f0539 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jun 13 11:33:45 2007 -0400 Remove some use of goto in the pacman frontend Refactor the goto cleanup; statements out of add.c and remove.c, and move what the cleanup: label did into a function. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 520841ee8a82460e0abb2a9a44c857556604cf56 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jun 13 10:36:33 2007 -0400 Quick updates to the bash completion script Signed-off-by: Dan McGee <dan(a)archlinux.org> commit a486fec3c48d57d48c7d871161c1510be10e0924 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sun Jun 17 18:57:15 2007 +0200 FS7338: Fix conflicts typo totally this time. The last typo fix for conflicts wasn't complete, it only fixed one occurence of the conflicts variable, instead of the two : http://www.archlinux.org/pipermail/pacman-dev/2007-May/008222.html This caused all conflicts statement to be ignored, so all databases will need to be rebuilt with a fixed repo-add. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> ----------------------------------------------------------------------- Diffstat: contrib/bash_completion | 25 +++++++++---------------- lib/libalpm/Doxyfile | 16 +++++++++++++++- lib/libalpm/db.c | 11 +++++++++++ scripts/repo-add.in | 2 +- src/pacman/add.c | 37 ++++++++++++++++++++++--------------- src/pacman/remove.c | 41 ++++++++++++++++++++++++++--------------- 6 files changed, 84 insertions(+), 48 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 7bd4486ebd15ba9cca0ee3e6a2c2ddc88ff104dc \ cacf968970bbc63e8eb519e40194e6c083ba6a06

1 0

[pacman-dev] How does pacman interact with a package's INSTALL script
by lordbad 16 Jun '07

16 Jun '07

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/

1 0

Re: [pacman-dev] [arch] Plans for switching to new package naming format (name-ver-rel -> name-ver-rel-arch)
by Dan McGee 15 Jun '07

15 Jun '07

On 6/13/07, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On 6/13/07, Johan Grahn <johan(a)cgeek.net> wrote: > > On Wed, 2007-06-13 at 22:43 +0100, Andrew Fyfe wrote: > > > Are there any plans (if so when) to switch the official repositories > > > over to the new package naming format? > > > > > > Current/Old: name-ver-rel.pkg.tar.gz > > > New: name-ver-rel-arch.pkg.tar.gz > > > > Why do you wanna do this? I'm just curios... > > > > Is it not better to just have separate repos because they are compiled > > differently and better to maintain. > > > > I'm not saying that is it a bad idea, I just wanna know how you think > > No body "wants" to do it - it's already done, and part of pacman 3.0. > The rationalization is simple: the majority of the time you don't > touch real package files... it's pacman -S, done. There is really > nothing lost from adding the suffix - what is gained is clarity in > looking at the filename. > > To respond to Andrew: there actually is no real "plan" at the > moment... but we want to make sure pacman2 users have sufficient time > to make the switch before we kill their packages. This drifts into something that should be on the pacman ML, so I'm moving it there. Is there any reason for pacman to enforce a naming convention at all when it comes to the packages? We should do any information gathering from the .PKGINFO file in the package itself rather than the name, shouldn't we? I also might be way off here- maybe pacman doesn't care. If so, let me know- I haven't dug into the code yet on this issue. -Dan

5 4

[pacman-dev] [patch] patch IV rewritten for git
by Nagy Gabor 13 Jun '07

13 Jun '07

Hi! Some comments: 1. This is a simple topological sort algorithm, based on the "depth first search" algorithm, for more info plz visit: http://en.wikipedia.org/wiki/Topological_sorting (An alternative algorithm for...) Usually this is done by a recursive way but I not prefer that, because this version is more expressive to me (however this looks more difficult, because we need some extra variables to precisely store the current state). 2. As I noted in the patch (TODO), the most CPU-cost part of the algorithm is to build the graph, so this should somehow combined with depcheck (because that function does this too...) So, here is the patch: ---------------------- diff --git a/lib/libalpm/Makefile.am b/lib/libalpm/Makefile.am index 29a2f02..afbfed0 100644 --- a/lib/libalpm/Makefile.am +++ b/lib/libalpm/Makefile.am @@ -43,7 +43,7 @@ libalpm_la_SOURCES = \ versioncmp.h versioncmp.c libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) -libalpm_la_LIBADD = -larchive -ldownload -lm +libalpm_la_LIBADD = -larchive -ldownload if HAS_DOXYGEN all: doxygen.in diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h index d4c584f..e6c905f 100644 --- a/lib/libalpm/alpm.h +++ b/lib/libalpm/alpm.h @@ -50,6 +50,7 @@ typedef struct __pmsyncpkg_t pmsyncpkg_t; typedef struct __pmdepend_t pmdepend_t; typedef struct __pmdepmissing_t pmdepmissing_t; typedef struct __pmconflict_t pmconflict_t; +typedef struct __pmgraph_t pmgraph_t; /* * Library diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c index b6f8cc8..ceee5c1 100644 --- a/lib/libalpm/deps.c +++ b/lib/libalpm/deps.c @@ -29,7 +29,6 @@ #ifdef __sun__ #include <strings.h> #endif -#include <math.h> /* libalpm */ #include "deps.h" @@ -46,6 +45,27 @@ extern pmhandle_t *handle; +pmgraph_t *_alpm_graph_new(void) +{ + pmgraph_t *graph = NULL; + + graph = (pmgraph_t *)malloc(sizeof(pmgraph_t)); + if(graph) { + graph->state = 0; + graph->data = NULL; + graph->father = NULL; + graph->sons = NULL; + graph->sonptr = NULL; + } + return(graph); +} + +void _alpm_graph_free(pmgraph_t *graph) +{ + alpm_list_free(graph->sons); + free(graph); +} + pmdepmissing_t *_alpm_depmiss_new(const char *target, pmdeptype_t type, pmdepmod_t depmod, const char *depname, const char *depversion) @@ -108,11 +128,10 @@ int _alpm_depmiss_isin(pmdepmissing_t *needle, alpm_list_t *haystack) alpm_list_t *_alpm_sortbydeps(alpm_list_t *targets, pmtranstype_t mode) { alpm_list_t *newtargs = NULL; - alpm_list_t *i, *j, *k, *l; - int change = 1; - int numscans = 0; - int numtargs = 0; - int maxscans; + alpm_list_t *i, *j, *k; + alpm_list_t *vertices = NULL; + alpm_list_t *vptr; + pmgraph_t *vertex; ALPM_LOG_FUNC; @@ -120,65 +139,64 @@ alpm_list_t *_alpm_sortbydeps(alpm_list_t *targets, pmtranstype_t mode) return(NULL); } + _alpm_log(PM_LOG_DEBUG, _("started sorting dependencies")); + + /* We create the vertices */ for(i = targets; i; i = i->next) { - newtargs = alpm_list_add(newtargs, i->data); - numtargs++; + pmgraph_t *vertex = _alpm_graph_new(); + vertex->data = (void *)i->data; + vertices = alpm_list_add(vertices, vertex); } - maxscans = (int)sqrt(numtargs); + /* We compute the edges */ + for(i = vertices; i; i = i->next) { + pmgraph_t *vertex_i = i->data; + pmpkg_t *p_i = vertex_i->data; + //TODO: this should be somehow combined with _alpm_checkdeps + for(j = vertices; j; j = j->next) { + pmgraph_t *vertex_j = j->data; + pmpkg_t *p_j = vertex_j->data; + int son=0; + for(k = alpm_pkg_get_depends(p_i); k && !son; k = k->next) { + pmdepend_t *depend = alpm_splitdep(k->data); + son = alpm_depcmp(p_j, depend); + free(depend); + } + if(son) vertex_i->sons=alpm_list_add(vertex_i->sons, vertex_j); + } + vertex_i->sonptr=vertex_i->sons; + } - _alpm_log(PM_LOG_DEBUG, _("started sorting dependencies")); - while(change) { - alpm_list_t *tmptargs = NULL; - change = 0; - if(numscans > maxscans) { - _alpm_log(PM_LOG_DEBUG, _("possible dependency cycle detected")); - continue; + vptr = vertices; + vertex = vertices->data; + while(vptr) { + vertex->state = -1; // we touched this vertex + int found = 0; + while(vertex->sonptr && !found) { + pmgraph_t *nextson = (vertex->sonptr)->data; + vertex->sonptr = (vertex->sonptr)->next; + if (nextson->state == 0) { + found = 1; + nextson->father = vertex; + vertex = nextson; + } + else if(nextson->state == -1) { + _alpm_log(PM_LOG_WARNING, _("dependency cycle detected\n")); + } } - numscans++; - /* run thru targets, moving up packages as necessary */ - for(i = newtargs; i; i = i->next) { - pmpkg_t *p = i->data; - _alpm_log(PM_LOG_DEBUG, " sorting %s", alpm_pkg_get_name(p)); - for(j = alpm_pkg_get_depends(p); j; j = j->next) { - pmdepend_t *depend = alpm_splitdep(j->data); - pmpkg_t *q = NULL; - if(depend == NULL) { - continue; - } - /* look for depend->name -- if it's farther down in the list, then - * move it up above p - */ - for(k = i->next; k; k = k->next) { - q = k->data; - const char *qname = alpm_pkg_get_name(q); - if(!strcmp(depend->name, qname)) { - if(!_alpm_pkg_find(qname, tmptargs)) { - change = 1; - tmptargs = alpm_list_add(tmptargs, q); - } - break; - } - for(l = alpm_pkg_get_provides(q); l; l = l->next) { - const char *provname = l->data; - if(!strcmp(depend->name, provname)) { - if(!_alpm_pkg_find(qname, tmptargs)) { - change = 1; - tmptargs = alpm_list_add(tmptargs, q); - } - break; - } - } + if(!found) { + newtargs = alpm_list_add(newtargs, vertex->data); + vertex->state = 1; //we leave this vertex + vertex = vertex->father; + if(!vertex) { + while(vptr = vptr->next) { + vertex = vptr->data; + if (vertex->state == 0) break; } - free(depend); - } - if(!_alpm_pkg_find(alpm_pkg_get_name(p), tmptargs)) { - tmptargs = alpm_list_add(tmptargs, p); } } - alpm_list_free(newtargs); - newtargs = tmptargs; } + _alpm_log(PM_LOG_DEBUG, _("sorting dependencies finished")); if(mode == PM_TRANS_TYPE_REMOVE) { @@ -189,6 +207,8 @@ alpm_list_t *_alpm_sortbydeps(alpm_list_t *targets, pmtranstype_t mode) newtargs = tmptargs; } + alpm_list_free_inner(vertices, _alpm_graph_free); + return(newtargs); } diff --git a/lib/libalpm/deps.h b/lib/libalpm/deps.h index 8f3a9b9..56028a4 100644 --- a/lib/libalpm/deps.h +++ b/lib/libalpm/deps.h @@ -42,6 +42,18 @@ struct __pmdepmissing_t { pmdepend_t depend; }; +/* Graphs */ +struct __pmgraph_t { + int state; //0: untouched, -1: entered, other: leaving time + void *data; + struct __pmgraph_t *father; //where did we come from? + alpm_list_t *sons; + alpm_list_t *sonptr; // points to a son in the sons list +}; + +pmgraph_t *_alpm_graph_new(void); +void _alpm_graph_free(pmgraph_t *graph); + pmdepmissing_t *_alpm_depmiss_new(const char *target, pmdeptype_t type, pmdepmod_t depmod, const char *depname, const char *depversion); diff --git a/src/pacman/Makefile.am b/src/pacman/Makefile.am index 6a7f4e4..1ab5916 100644 --- a/src/pacman/Makefile.am +++ b/src/pacman/Makefile.am @@ -26,11 +26,11 @@ pacman_SOURCES = \ util.h util.c pacman_LDADD = $(top_builddir)/lib/libalpm/.libs/libalpm.la \ - -ldownload + -ldownload -lm pacman_static_SOURCES = $(pacman_SOURCES) pacman_static_LDFLAGS = $(LDFLAGS) -all-static pacman_static_LDADD = $(top_builddir)/lib/libalpm/.libs/libalpm.la \ - -ldownload + -ldownload -lm # vim:set ts=2 sw=2 noet:

4 6

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-231-g7bd4486
by Dan McGee 13 Jun '07

13 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 7bd4486ebd15ba9cca0ee3e6a2c2ddc88ff104dc (commit) from af813a8badd71c591a8c29d9bad1710ae3b2e945 (commit) - Log ----------------------------------------------------------------- commit 7bd4486ebd15ba9cca0ee3e6a2c2ddc88ff104dc Author: Andrew Fyfe <andrew(a)neptune-one.net> Date: Wed Jun 13 10:48:22 2007 +0100 scripts/makepkg.in: Forgot the fakeroot switch when changing to GNU getopt. Signed-off-by: Andrew Fyfe <andrew(a)neptune-one.net> ----------------------------------------------------------------------- Diffstat: scripts/makepkg.in | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ af813a8badd71c591a8c29d9bad1710ae3b2e945 \ 7bd4486ebd15ba9cca0ee3e6a2c2ddc88ff104dc

1 0

[pacman-dev] Add fakeroot version to .PKGINFO header
by Andrew Fyfe 13 Jun '07

13 Jun '07

I've created a small patch (on my ready_to_pull branch) that adds the version of fakeroot to the header of .PKGINFO: # Generated by makepkg 3.1.0-dev # using fakeroot version 1.7.1 This is purely for debugging. I've currently got a couple of packages with wrong permissions which I think are a result of the coreutils/fakeroot bug from a couple of months ago (http://archlinux.org/news/310/) Andrew http://repo.or.cz/w/pacman.git?a=shortlog;h=ready_to_pull

2 2

[pacman-dev] Problems with alpm
by Georg Grabler 13 Jun '07

13 Jun '07

Hey guys, I'm once again having problems with the code in alpm. I can't seem to find out how to correctly register databases. I've the bindings basically ready, and need to do the implementation now (pyalpm). So, the following problem occured: I set the database path to /var/lib/pacman (or /var/lib/pacman/community, tried both). It seems as if alpm_option_set_dbpath can't cause errors (void return), so i ignored it. alpm_trans_init runs without returning -1, so i expect it to be succeeded. On alpm_trans_addtarget, i finally get the -1, with pm_errno 11, meaning PM_ERR_DB_NULL. I don't know (lacking docs) what this means, and why this can occur. Do you have any hints for me? Some codelines: cdef pyalpm_config c_config c_config = pyalpm_config() config = c_config alpm_initialize() def addPackage(in_pname) db = config.getDatabasePath() print db # output is OK pyalpm_db_register('community') if (alpm_trans_init(PM_TRANS_TYPE_ADD, <pmtransflag_t((<int>PM_TRANS_FLAG_CASCADE) | (<int>PM_TRANS_FLAG_RECURSE)), NULL, NULL, NULL) == -1): os.remove("/tmp/pacman.lck") print pm_errno return -1 if (alpm_trans_addtarget(in_name) == -1): os.remove("/tmp/pacman.lck") print pm_errno return -2 # here it exits ###test.py### import pyalpm pyalpm.config.setDatabasePath('/var/lib/pacman') print pyalpm.addPackage('yaz') ###output### 11 -2 Seems as if i'm missing something -- Yours, Georg (STiAT)

3 2

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-230-gaf813a8
by Dan McGee 13 Jun '07

13 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 af813a8badd71c591a8c29d9bad1710ae3b2e945 (commit) via 620a811f9136feb332a0f196a6f9a8818368c908 (commit) via 5e774d72b0ac7777aada8271e2162d764d4f0db4 (commit) via caf6c326ec9a376ffb794051cd09c40abc135fda (commit) via 83245aa58ef1eefcc3498a82923e55bc799ca361 (commit) via 54b71f0427e87e6d525423df06f8a06f2b71c518 (commit) from e2a75a8257e3402c32a208709f044373ef97caf7 (commit) - Log ----------------------------------------------------------------- commit af813a8badd71c591a8c29d9bad1710ae3b2e945 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jun 13 00:55:23 2007 -0400 Add ARM architecture to configure.ac Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 620a811f9136feb332a0f196a6f9a8818368c908 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jun 13 00:34:43 2007 -0400 Clean up pacman/sync.c and organize it a bit Re-add some checks for a valid target list. In addition, move variable declarations to the most local scope possible, which should help in finding errors that were previously uncaught. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 5e774d72b0ac7777aada8271e2162d764d4f0db4 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jun 13 00:31:01 2007 -0400 Remove some more diskspace checking holdover stuff Signed-off-by: Dan McGee <dan(a)archlinux.org> commit caf6c326ec9a376ffb794051cd09c40abc135fda Author: Dan McGee <dan(a)archlinux.org> Date: Tue Jun 12 23:55:14 2007 -0400 Functionalize query.c and pacman_query Move a lot of the operations that pacman query performs into their own functions for ease of following the flow and for possible later merges with their sync counterparts. We need to think less in terms of operations and more in term of overall concepts. Also (re)introduced checks for the target list on a -Q operation, ensuring that we only call certain query operations when it is sane to do so. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 83245aa58ef1eefcc3498a82923e55bc799ca361 Author: Andrew Fyfe <andrew(a)neptune-one.net> Date: Tue Jun 12 23:30:56 2007 +0100 scripts/makepkg.in: Added fakeroot version to .PKGINFO header. Signed-off-by: Andrew Fyfe <andrew(a)neptune-one.net> commit 54b71f0427e87e6d525423df06f8a06f2b71c518 Author: Andrew Fyfe <andrew(a)neptune-one.net> Date: Tue Jun 5 11:58:25 2007 +0100 scripts/makepkg.in: Switch to GNU getopt. Signed-off-by: Andrew Fyfe <andrew(a)neptune-one.net> ----------------------------------------------------------------------- Diffstat: configure.ac | 5 + lib/libalpm/alpm.h | 1 - lib/libalpm/error.c | 2 - scripts/makepkg.in | 129 +++++++++--------------- src/pacman/add.c | 14 --- src/pacman/query.c | 280 +++++++++++++++++++++++++++++++-------------------- src/pacman/sync.c | 61 ++++++++---- 7 files changed, 263 insertions(+), 229 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ e2a75a8257e3402c32a208709f044373ef97caf7 \ af813a8badd71c591a8c29d9bad1710ae3b2e945

1 0