Versioned tag information

[Andrea Bolognani]

On Mon, 05 Feb 2007 08:28:42 +0100
Benjamin Mesing <bensmail at gmx.net> wrote:

> > Can you please give an example scenario, and explain exactly *in which*
> > versions Tag-Set: and Tags-Diff: are used?
>
> Scenario 1 usage of Tag-Set
> ----------------------------
> Package firefox 1.3 tagged "use::browsing" "works-with::html" becomes a
> dummy package in 2.0.
> So the control field is set to
>         Tag-Set: role::dummy
> If someone adds a tag  "web::browser" to version 1.3, this tag will not
> be set for 2.0
>
>
> Scenario 2 usage of Tag-Diff
> ----------------------------
> Package packagesearch is tagged "uitoolkit::qt", "use::searching" in
> version 1.3.
> With the release of version 2.0 packagesearch gains the ability to
> install packages, so it can be considered a full package-management
> tool.
> The Control-Field for 2.0 is
>         Tag-Diff: +use::package-management
>
> If someone adds a tag  "implemented-in::c++" to version 1.3, this tag
> will also be set for 2.0.

Now I get it, thanks for the example.

> Because in my opinion the flexible approach is superior to the static
> one. That everything else is done one way, does not necessarily mean,
> that it is the best way of doing it.
> I do believe, that we will get better results with the community driven
> tagging approach as opposed to the maintainer centric one (since tag
> information is non-critical information). Please see my earlier posts
> for my reasoning behind this opinion.
> Especially we have a very long period ahead, where the tagging
> information needs to be completed (among other reasons, because the
> vocabulary is not yet stable).

Stable is static by definition. How can we provide stable's users with fresh
tags?

An updated Packages file would do. Would it be feasible to use
security-updates' Packages file to provide fresh tags to stable's users?

> > > Also, once a
> > > Debian distribution is release, there is no way to change the tagging
> > > information. IMO leaving the possibility to fix the tagging open, would
> > > be benefitial.
> >
> > Once a release is made, the tag set for that release should be frozen
> > anyway.
>
> I disagree. We can't change the packages after a release, since the
> risks are to big -- the software might break. But tagging information is
> much less critical, and thus could benefit from further improvement.

Of course this is true.

> > Just like any other thing. Tags could be updated for point releases, of
> > course, or via security-updates (I'm not sure how security-updates work, so
> > I could be saying nonsense).
>
> Security updates are just that, security updates. Perhaps some kind of
> volatile support might work.

The reason why I was thinking about security-updates is because it provides a
Packages file (so we could put updated tags there) and because most stable
users will get updates from it.

--
KiyuKo <eof AT kiyuko DOT org>
Resistance is futile, you will be garbage collected.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20070205/e1885e13/attachment.pgp