Re: Transitional (dummy) packages considered silly
On Sun, Sep 27, 2009 at 04:30:50PM +0200, Stefano Zacchiroli wrote:
> - Status quo: grepping for "transitional package" in package
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.
Francesco P. Lovergine