David Paleino wrote: > Eugene V. Lyubimkin wrote: >> 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. > > We can always change our tools to comply with that, no? :) Well, yes, but I don't think that modifying low-level package manager is justified for high-level package manager issues, and I suspect dpkg developers will agree with me in this question.
> # apt-get install metapackage > # apt-get --purge remove dependency1 > > At this point, "dependency1" gets blacklisted or -- if you prefer -- the > package manager sets is pin to -infinity. > > # apt-get clean-blaclist metapackage > > The "blacklist" for metapackage gets cleaned, and, at the same time, a "apt- > get --reinstall install metapackage" is issued. I see some benefits for this approach, but IMHO it's a bit over-engineered - one will need to generate several new commands (view blacklist, view list of blacklists, already mentioned clean/change-blacklist, maybe something else), plus it adds even more complexity to already complex problem resolver subsystem - not I would want to implement, personally. >> To summarize: if I am not mistaken, this DEP cannot be implemented due to >> technical reasons in its current form. > > Could you please expand this a bit? > Adding a new field to debian/control always needs a change in our tools > and > this one touches package managers. What's wrong with this? :) This one needs changes in dpkg. While, for example, fiddling with Recommends may require some changes only from high-level package managers. To rephrase, I don't see any future for this DEP before you get dpkg developers approval for special-handling for meta-packages. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature