On 03/02/10 09:33, Nagy Gabor wrote:
On 02/02/2010 09:13 PM, Nagy Gabor wrote:
This is not the competent ML to decide if ArchLinux's repos should use
these flags, personally I have some concerns about db.tar.gz size. (That
needs testing, which requires patched makepkg, too.)

I've repacked core and the results are quite good:

core.db.tar.gz from 35KB to 40KB
unpacked db from 2.1MB to 2.2MB


Here is a little explanation for this nice result:

Florian's patch puts a library into sodepends iff the .so file is owned
by one of its _direct_ dependencies (optdepends are omitted). That is
why the "sodepends" array is shorter than expected (by me).

You may say this method is not as safe as it should be, but imho it
is safe enough (if the user doesn't use the -d switch, of course):
For example, yesterday I broke all my gtk2 packages due to my custom
cairo build (I should have rebuild it with recent libpng). With
soprovides/sodepends enabled, pacman would catch the broken
cairo-cleartype->libpng dependency in the firefox->gtk2->cairo->libpng
dependency chain. So in sum, sodepends/soprovides trick is just ensures
that all "normal" dependencies are not broken in .so level neither.

Moreover, due to this feature, distros can introduce
sodepends/soprovides step-by-step (without rebuilding all packages in
the repo), or they can limit this feature to some "critical" packages.


Basically, +1 for implementing this to makepkg and use this in
ArchLinux's repos. (Although this ML is not competent ;-)

I can see only one edge case that should be addressed (that's why I'm
writing this e-mail): Dependencies can be satisfied via provision. What
to do then? (That is not handled at all atm.)

I will have a decent look into that patch later, but I still think it is a bit of a false sense of security.

e.g readline-6.0 and readline-6.1 both provide libreadline.so.6. However, building bash against readline-6.1 and running against readline-6.0 results in a non-booting system... (Trust me, I got the bug reports). If this approach does not work for even one of the most critical pair of packages on a system, then I do not see what we are gaining.

Finally, this would prevent proper upgrades to partially complete rebuilds. That is fine for some users who would like such things, but the people doing and testing a rebuild would have issues. I upgraded the libpng/libjpeg rebuild packages while there were still several packages needing to be rebuilt for my system. With this patch, I would be required to do an incredibly stupid "pacman -Syud".

Allan

Reply via email to