[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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 

pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>

Reply to: