[arch-general] Please settle 'base' in 'depends' for all
Okay everyone, every time I ask I get a different answer. According to Dziedzic and Allan 'glibc' does *not* belong in 'depends'. Also Dziedzic votes that *no* package in 'base' should be in 'depends'. Can we settle once and for all what the correct policy is? And then can we update the wiki page and all of these packages http://www.archlinux.org/packages/core/i686/glibc/so that they reflect the policy? --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
On Wed, 19 Jan 2011 00:19:50 -0500, Kaiting Chen wrote:
Okay everyone, every time I ask I get a different answer. According to Dziedzic and Allan 'glibc' does *not* belong in 'depends'. Also Dziedzic votes that *no* package in 'base' should be in 'depends'. Can we settle once and for all what the correct policy is? And then can we update the wiki page and all of these packages http://www.archlinux.org/packages/core/i686/glibc/so that they reflect the policy? --Kaiting.
Every direct dependency needs to be listed in depends even if that for dependencies that are in base. This is important because packages might appear and disappear in the base group and last but not least pacman needs to know in which order packages need to be installed. The last one is especially important for the installer. We also cannot assume that people have installed every package from the base group. This is different for packages from base-devel though. They don't need to be listed as makedepends. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 19/01/11 15:19, Kaiting Chen wrote:
Okay everyone, every time I ask I get a different answer. According to Dziedzic and Allan 'glibc' does *not* belong in 'depends'. Also Dziedzic votes that *no* package in 'base' should be in 'depends'. Can we settle once and for all what the correct policy is? And then can we update the wiki page and all of these packages http://www.archlinux.org/packages/core/i686/glibc/so that they reflect the policy? --Kaiting.
In general, I think packages in 'base' need listed. Mainly because I do not install a fair number of the base packages and would have even less of them installed if they were not listed as dependencies. However, I think listing 'glibc' in depends is a waste of time. If a system does not have glibc installed, there are worse issues than a missing dependency for one package... If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. We never know what dependencies will be removed on an update of a package in the dep chain. But we don't do this? Why? Because it means pacman has to make less dependency checks and thus the whole update process is a little faster, and it is more convenient to not have to explicitly list everything. For those same reasons, I see no need to list glibc as a dependency, especially for packages in [extra] and [community]. Allan
On Wed, 19 Jan 2011 17:08:27 +1000 Allan McRae <allan@archlinux.org> wrote:
On 19/01/11 15:19, Kaiting Chen wrote:
Okay everyone, every time I ask I get a different answer. According to Dziedzic and Allan 'glibc' does *not* belong in 'depends'. Also Dziedzic votes that *no* package in 'base' should be in 'depends'. Can we settle once and for all what the correct policy is? And then can we update the wiki page and all of these packages http://www.archlinux.org/packages/core/i686/glibc/so that they reflect the policy? --Kaiting.
In general, I think packages in 'base' need listed. Mainly because I do not install a fair number of the base packages and would have even less of them installed if they were not listed as dependencies.
If we allow users to not (explicitly) install base packages and support such schemes by adding more detailed dependencies, then we could just as well scratch the base group, because it becomes pointless. Actually I would prefer this approach: throw the concept of the base group away, all the *needed* packages will get installed anyway, because they are dependencies for packages the user explictly wants. Dieter
participants (4)
-
Allan McRae
-
Dieter Plaetinck
-
Kaiting Chen
-
Pierre Schmitz