April 2010 - Pacman-dev - lists.archlinux.org

[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