FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 01-17-2010, 03:27 PM
Pierre Schmitz
 
Default Please avoid versioned deps

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.html

This is just a general reminder and I did not intend to attack anyone. So
just keep it simple. :-)

Greetings,

Pierre

--
Pierre Schmitz, https://users.archlinux.de/~pierre
 
Old 01-28-2010, 03:23 PM
Pierre Schmitz
 
Default Please avoid versioned deps

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.

--

Pierre Schmitz, https://users.archlinux.de/~pierre
 
Old 01-28-2010, 03:44 PM
Ionut Biru
 
Default Please avoid versioned deps

On 01/28/2010 06:23 PM, 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?


-1


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 think in this way we will have major breakage. For example:
http://bugs.archlinux.org/task/18051
if bash had an extended version on readline dependency he wouldn't
trash his system. The examples can be a lot. External modules(which are
in extra) they have kernel26>=2.6.32 kernel26<2.6.33 just to avoid
breakage.


--
Ionut
 
Old 01-28-2010, 03:55 PM
Pierre Schmitz
 
Default Please avoid versioned deps

Am Donnerstag, 28. Januar 2010 17:44:48 schrieb Ionut Biru:
> > 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?
>
> -1
>
> > 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 think in this way we will have major breakage. For example:
> http://bugs.archlinux.org/task/18051
> if bash had an extended version on readline dependency he wouldn't
> trash his system. The examples can be a lot. External modules(which are
> in extra) they have kernel26>=2.6.32 kernel26<2.6.33 just to avoid
> breakage.

If you had read my proposal you would have noticed that this would have made
this breakage impossible; bash is in the base group. And I think we can add
kernel modules here, too.

--

Pierre Schmitz, https://users.archlinux.de/~pierre
 
Old 01-29-2010, 12:39 AM
Allan McRae
 
Default Please avoid versioned deps

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
 

Thread Tools




All times are GMT. The time now is 08:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org