On 29/01/10 02:23, Pierre Schmitz wrote:
Am Sonntag, 17. Januar 2010 17:27:57 schrieb Pierre Schmitz:
Hi all,
recently I have seen that there were a lot of commits introducing versioned deps down to the pkgrel level. I think we should avoid such deps if possible. There are possibly only some important packages in core where this is useful and in such cases you should add not only an lower but upper bound (see kernel modules for example).
For anything else this is not needed (at least for Arch), adds more complexity or simply breaks stuff. For more detailed arguments please read at least the first three messages in http://mailman.archlinux.org/mailman/private/arch-dev/2009-October/011439.h tml
This is just a general reminder and I did not intend to attack anyone. So just keep it simple. :-)
Greetings,
Pierre
What do you think if we work on some kind of policy that recommends strict versioned deps for packages in the base group and none for everything else?
This way we could avoid any major damage (caused by users, mirror problems or even our fault) but on the other hand does not introduce complexity and other problems for non-base packages.
I really, really dislike versioned deps. I do not see what it solves. It allows people to partially update their system (either deliberately or by install a package with pacman -Sy <pkg>), and those packages installed or updated get the correct version of deps. However, that completely breaks every other package requiring anything that was updated in the process. The problem with versioned deps is that they can either not strict enough or too strict. Too strict means extra rebuilds that were not actually necessary. Not strict enough means that they are useless. Take for example bash. It has a readline>=6.0 dep. That should have been fine as there was no soname change going from readline 6.0 to 6.1, but it is not. It really needs readline>=6.1. So that was not strict enough, but changing it still does not make it strict enough to avoid future breakage e.g. when there is a readline soname bump. We could provides/depends on soname, but with the current bash/readline issue there would still have been breakage, so we would require soname dep plus a versioned package dep. So my conclusion is versioned deps are a false sense of security and are more of a hassle than is needed. We should never use them unless there are definite upper and lower bounds; e.g. kernel modules. Well, that is not even definite given this kernel the lower bound changed from 2.6.32 to 2.6.32.4... Can a out-of-date mirror actually cause issues. The repo db is still consistent with itself, so the answer should be no. The only way I can see breakage is users stupidly updating part of their system, or rare cases like the current bash/readline bug report where the user has a corrupt local db. Both cases, we can really do nothing about. Allan