On Wed, Apr 7, 2010 at 12:31 PM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Wed, Apr 7, 2010 at 6:23 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Wed, Apr 7, 2010 at 10:16 AM, Allan McRae <allan@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 ?
Make vercmp in pacman proper build clean (e.g. no library deps) via including the vercmp code from alpm directly without doing a copy-paste job. I have some local testing for this in the works. -Dan