On Sun, Sep 27, 2009 at 04:30:50PM +0200, Stefano Zacchiroli wrote: > > - Status quo: grepping for "transitional package" in package > descriptions >
Transitional packages are often not defined as such in description. Too unsafe rely on keyword such as transitional, dummy, what else. This is sub-optimal IMHO. > - Archive section (i.e. Frankie's proposal): would ftp-master (Cc-ed) > be willing to pursue that road? > > - Debtags. Apparently there's already a tag "role::dummy" whose > semantics seems to match "transitional package" (hence the name should > probably be better?). > That could be an alternative, but I would prefer a solution under full maintainer's control. Debtags currently is not AFAIK. And this is probably the reason of the mismatches below. > However, if I check on my laptop I've about 20 transitional packages > installed (detected using "status quo" above) and some empiric tests > show that quite a lot of them do not have the "role::dummy" tag. This > means that, at least currently, the debtags way is not really enough > (or better: it looks to be sound, but not complete). I wonder why? Is > it just missing tags or is there some more serious infrastructure > problem? E.g.: is there a tag flow problem which "erases" tags from > transitional package of past versions when the package got removed > from the archive (but not necessarily from user machines?). Cc-ing > debtags-devel for advices. > > - A new debian/control field, e.g. "Transitional: yes" > This is equivalent to the archive solution, but it increases fields pollution. I have not a strong opinion about what's better. > > I see no clear winner among the above choices. The proposed solution of > using archive sections, for instance, has the drawback that you renounce > to the "original" section and hence you will partly defeat user actions, > e.g., removing all installed packages belonging to a given section. > I see no uses for such a selective removing. But that could be a pro for the control field. > Debtags is clearly meant to solve this problem, but for transitional > packages I'd like to have a solution which is both sound and > complete. Only with such properties I'd be confident of integrating a > clean up actions which we can recommend doing, e.g., in release notes. > > Thoughts? > -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org