Re: [RFC] DEP-6: Meta-Package debian/control field
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>
Reply to: