- Pacman-dev - lists.archlinux.org

[pacman-dev] pactree reverse dependancies
by Christophe Chapuis 15 Apr '10

15 Apr '10

Hello all, I just added an option to pactree, in order to look for reversed dependancies of a package instead of the normal dependancies. I already sent a mail to carlocci, who was the initial developper of this script, but as he doesn't answer I wonder if I should contact someone else. So, what should I do with this little patch? Attach it here in the mailing list? Tofe

2 5

[pacman-dev] .so provides/depends patches review
by Allan McRae 14 Apr '10

14 Apr '10

Hi, Sorry this has taken me a while... so long in fact that I do not have the original email stored anymore to reply to. But here goes my comments on the patches for soname provides/depends: http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/010431.html My comments are currently only on functionality. I'll get to code after that is fully sorted. Firstly, it works well and does as advertised. So no issues there... However: 1) If I put a bad soname provides in the array (e.g. provides="readline.so") it just silently ignores it. No error and nothing put in the .PKGINFO. There needs to be an error (or at minimum a warning). The same goes for depends (although these are mostly caught by the initial dependency checking in makepkg). 2) Building readline on i686 with provides="libreadline.so", in the .PKGINFO I get: provides = libreadline.so=6-elf32_i386 My concern about that is that the library is not i386 but is i686. I may be prepared to accept that though as I guess x86 is x86 really... But what additional information is the elf32 providing? I could perhaps understand the operating system from the host triplet. If anything, my preferences are: libreadline.so=6-i686_linux (best) libreadline.so=6-i686 / libreadline.so=6-i386_linux libreadline.so=6-i386 (worst) Allan

4 5

[pacman-dev] [PATCH] makepkg: warn about repackaging without a package function
by Allan McRae 14 Apr '10

14 Apr '10

File permissions are not guaranteed to stay the same on exit from fakeroot, so repackaging may result in files with different permissions. This is avioded when using a package() function (or split packages) as the packaging step is rerun. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- Two areas to comment on: 1) "makepkg -R --asroot" does not give this warning. This is because it is assumed that the initial packaging stage was also done as root and so file permissions will be correct. Is that a fair assumption? 2) Should we depricate repackaging without a package function in pacman-3.5? Using a package function was supported in 3.3 and using only a package function (no build function) will be supported in 3.4. If that is reasonable, I will alter the warning and add it to the --asroot case too. scripts/makepkg.sh.in | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index b2b449c..09a99e1 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1847,9 +1847,14 @@ fi if (( INFAKEROOT )); then if (( ! SPLITPKG )); then if (( ! PKGFUNC )); then - if (( BUILDFUNC && ! REPKG )); then - run_build - tidy_install + if (( ! REPKG )); then + if (( BUILDFUNC )); then + run_build + tidy_install + fi + else + warning "$(gettext "Repackaging without the use of a package() function may not")" + plain "$(gettext "preserve file permissions.")" fi else run_package -- 1.7.0.5

2 1

[pacman-dev] implement .so dependencies?
by Florian Pritz 13 Apr '10

13 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Regarding the current mass rebuilds because of libpng I'd like to suggest implementing so dependencies again. There will be no more cases where packages break because of library updates and as a nice side effect AUR users see what they have to rebuild. Pacman will treat those dependencies like others so if a user is sure he wants to update he can use -Sd. I've also tested if packages with sodeps would slow down pacman operation, but that's not really the case. The current patch adds "sodep-$arch-$soFileName" for every .so file that's owned by a package in the depends array. Files from optdepends are silently ignored and if no dependency owns the file there will be a warning. I've just rebased the old patch onto HEAD, fixed a little bit and tested it with libjpeg, so it should be fine. - -- Florian Pritz -- {flo,bluewind}(a)server-speed.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLWgg0AAoJEG0WVcFM4cE+xlYP/08Ec1K9gFz0g8Q/+ag4S8+S U9mInCwJTe9xnu+H1J9JRsMwZ8DzP8WUlc99pqgz9n9Nxk8cpE1eUU9IIluHzjvR bJglYvAKIIknEtc1OkLVicFW2OfvgNzSwx73W6J3fELlzABpxtEMwmmXAJMaVZKq aIVgZ/zFP5b6XJT14FfQJbR7Mj4V5mCAhY0W+5SJL58RIHxPRz1PJKbzuZUcqLBo ouBcBPH9YuiSKufJhbsowyE6Hfyg4btFVHktr7EBvHtB/nb8Kk09LduloaQ9ZtEl hdSlbQL36AI2xJdN4XyuP4+UKmSh4hJKxfVBBCcDeWZd4ZbcC4WIersBY4Ia3hle 96Z8IZG8ydfC6+Ii5wdhdgzwzgaI2ZitgzO/XTLvBB1xpL+gQpupcSFSuypiU0K0 Yz3gybnj1XKb/8UEpNgjuKu6G1UChnmbenSS6lYFotXNWilQM9kAkYTDMV/KoQa0 CeyflEuUJuggMsKPz71NJnRCxcXSEdhVebeB9jKX8l2TIOgHwIYmmbO3yMaowzF+ 39zEAgxYxaLlTXQ2mnL/OkPrFjNQ1exyWwD1nW1N8n7Sr0zT21P4XK8kOrCQlTp7 XswSeZBV+pfR2Uby5hU6tUW9UvWZOHq2YZB7SAWfI7IEzcQxyVcbwwjuxplVgUr+ whZlxxDSfR0k6Uc9jeGm =/iDR -----END PGP SIGNATURE-----

9 28

[pacman-dev] [PATCH] Fix a mistake in the cross-compilation fix
by Matthias Lanzinger 09 Apr '10

09 Apr '10

I noticed a serious mistake in my previous patch. -lssl and -lcrypto were beeing added to $LIBS and by that they were added as linker flags during compilation. This overruled the --as-needed flag and causes ssl to be directly linked to pacman. Signed-off-by: Matthias Lanzinger <mlaenz(a)gmail.com> --- configure.ac | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index d0fed48..9bb0cd1 100644 --- a/configure.ac +++ b/configure.ac @@ -142,8 +142,8 @@ if test "x$internaldownload" = "xyes" ; then AC_MSG_RESULT(yes) AC_DEFINE([INTERNAL_DOWNLOAD], , [Use internal download library]) # Check for a download library if it was actually requested - AC_CHECK_LIB([fetch], [fetchParseURL], [AC_SUBST([LIBS], ["-lfetch -lssl -lcrypto -ldl $LIBS"])], - AC_MSG_ERROR([libfetch is needed to compile with internal download support]), [-lssl -lcrypto -ldl] ) + AC_CHECK_LIB([fetch], [fetchParseURL], [AC_SUBST([LIBS], ["-lfetch -ldl $LIBS"])], + AC_MSG_ERROR([libfetch is needed to compile with internal download support]), [-lcrypto -ldl] ) # Check if libfetch supports conditional GET # (version >=2.21, struct url has member last_modified) AC_CHECK_MEMBER(struct url.last_modified, , -- 1.7.0.3

3 2

[pacman-dev] pacman output wrapping on hurd
by Allan McRae 09 Apr '10

09 Apr '10

Hi, On Arch Hurd, I am seeing weird output from pacman. See http://allanmcrae.com/images/pacman-hurd.png (sorry, qemu image so cut/paste is hard). Basically, it is wrapping the output any time there is a whitespace. Any ideas on what is causing that? Arch Hurd is still in its infancy (barely a toolchain and makepkg deps, but it boots!), so it may be something basic in the system is still missing. Allan

2 2

Re: [pacman-dev] [arch-dev-public] [arch-general] WARNING: [testing] broken due to openssl and heimdal rebuilds
by Xavier Chantry 07 Apr '10

07 Apr '10

On Wed, Apr 7, 2010 at 6:23 PM, Dan McGee <dpmcgee(a)gmail.com> wrote: > On Wed, Apr 7, 2010 at 10:16 AM, Allan McRae <allan(a)archlinux.org> wrote: >> On 08/04/10 00:54, Florian Pritz wrote: >>> >>> On 07.04.2010 16:10, Allan McRae wrote: >>>> >>>> This would really not help here. Pacman does not directly link openssl, >>>> but does through libarchive and libfetch. Adding versioned libarchive >>>> and libfetch to pacman's deps and using sodeps on openssl in those >>>> packages would prevent pacman's SyncFirst from working. >>>> >>> >>> Don't add depends=(libfetch.sp libarchive.so) to the pacman PKGBUILD and >>> it won't be a problem. (Also see #2 below) >> >> Adding those or not is the same as adding versioned deps or not. Both cause >> bad issues. >> >>>> no versioned deps in pacman for lib{archive,fetch} = bad as between the >>>> openssl and lib{archive,fetch} updates vercmp is broken and so is >>>> install files. >>> >>> sodeps would ensure that pacman updates libfetch and libarchive directly >>> after openssl. >> >> Not directly after, but in the same transaction. That is the same as the >> current issue we have. Using sodeps is no improvement over versioned deps >> here. > > Allan and I talked a bit on IRC and we both came to some idea that a > vercmp without any deps would probably be a good solution. We can hack > this up for now, file attached to do so. > > If this goes into the pacman package dir in SVN and we just add a "gcc > -O2 -o vercmp vercmp.c" in there and put it in the right place, we can > avoid a lot of hassle with everything here. > That sounds fine, but what is the long term solution exactly ?

2 1

[pacman-dev] [PATCH] Add vim modeline to PKGBUILD-split.proto
by David Campbell 04 Apr '10

04 Apr '10

Add the vim modeline that is in PKGBUILD.proto to PKGBUILD-split.proto so they are consistent with each other. --- PKGBUILD-split.proto | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/PKGBUILD-split.proto b/PKGBUILD-split.proto index 68a8cc4..53a3e8f 100644 --- a/PKGBUILD-split.proto +++ b/PKGBUILD-split.proto @@ -61,3 +61,5 @@ package_pkg2() { cd "$srcdir/$pkgbase-$pkgver" make DESTDIR="$pkgdir/" install-pkg2 } + +# vim:set ts=2 sw=2 et: -- 1.7.0.3

2 1

[pacman-dev] Why alpm_list.h?
by Moritz Wilhelmy 02 Apr '10

02 Apr '10

Hello, since I started to dig into pacman's code, I've also started to wonder why exactly libalpm reinvents the wheel by using it's own list implementation rather than sys/queue.h (see QUEUE(3) for details). Is it for backwards compatibility or what are the exact reasons to handle it this way? Kind Regards, Moritz

2 1

Re: [pacman-dev] [arch-dev-public] openssl 1.0 rebuild
by Xavier Chantry 02 Apr '10

02 Apr '10

On Fri, Apr 2, 2010 at 2:46 AM, Allan McRae <allan(a)archlinux.org> wrote: > > I'd just remove it. > > Basically the arguement against widespread usage of versioned deps is if you > put a versioned openssl>=1.0 there and someone does "pacman -Sy mutt", it > will pull in the new openssl and break many packages on their system. If > you do not put it there, it will only break mutt. > Wasn't it in http://honestknave.com/2009/07/18/the-arch-package-management-debacle/ (unfortunately dead) that the guy did the following : 1) pacman -Sy mutt oh damn mutt is broken because of openssl, let's upgrade openssl 2) pacman -S openssl boom, we are back in the versioned dep case. IIRC this was the post that led to this FR : http://bugs.archlinux.org/task/15581

1 0