Eugene V. Lyubimkin writes: > Hello, > > David Paleino wrote: > > Implementation > > [...] > > > ### Package managers ### > > [...] > > > If any dependant package is a meta-package, as defined by this > > document, it should **NOT** be removed, opposed to what the current > > implementations do. The package manager should then add the removed > > package to a "blacklist" for the dependant meta-package. This allows > > for upgrades of the meta-package without re-installing everything again, > > i.e. the package manager should check the dependencies of the > > meta-package against its blacklist, if present. > > No, it doesn't. Dpkg and any sane high-level package manager won't consider > installing/upgrading/keeping some package (meta or not) without all Depends > installed.
I agree. That flies directly in the face of Policy definition of Depends: <cite> This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured. </cite> Degrading such a base and well established feature looks like a criminal act, at best ;-) > What you described above seems more like 'Recommends'-handling to me, and > some high-level package managers (I can say for cupt) have some logic to > not install the same recommended packages again if they were not installed > or removed when upgrading "parent" packages. > > > #### Blacklist management #### > > Package managers should allow for deletion of the blacklist upon > > removal of the meta-package. > > > > Moreover, they should allow the deletion of the blacklist, and the > > installation of the missing meta-package dependencies at the same time. > > The "blacklist" support also is already present somewhere (speaking of > cupt, you can set pin like "-2000" to some package, and it won't be pulled > for Recommends/Suggests). > > > To summarize: if I am not mistaken, this DEP cannot be implemented due to > technical reasons in its current form. Yes, this could be corrected. Moreover, I imagine that having metapackages clearly identified via boolean Meta-Package field, would help searching based on a dedicated field, since currently the only way I'm currently aware of to identify all metapackages is by matching Description field (apt-cache search ^metapackage) which is not even remotely reliable of course. Of course new fields shouldn't be added lightly, and I can imagine people opposing that as well. -- pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
