Versioned tag information

[Enrico Zini]

On Sun, Feb 04, 2007 at 11:43:40AM +0100, Benjamin Mesing wrote:

> Now, someone working on unstable submits the tag
> "admin::package-management" for the package and the version he is using
> (2.2.5). Like with versioned bugs, the package will, starting from
> version 2.2.5, have the tag. The stable version will not have the tag
> (packagesearch wasn't capable of managing packages back then).
> If someone submits the tag to the stable version, the unstable version
> will also have the tag.
> Tag sets for stable, testing and unstable could be generated from the
> central database, which holds all the versioned tag information.

The data is rather easy to collect, but it would require to implement a
different format than the current tag patch for transmitting tag
information to the server.

Another work that is precondition for this change is to have the central
database store package versions together with tag patches.  Currently,
the storage format is the same as /var/lib/debtags/package-tags, which
doesn't store versions.

It might be an excuse to move to XML or even RDF, but that will mean
work, of a kind that, I confess, doesn't attract me at the moment.

A more workable solution would be to ship and store, together with each
patch, a file which lists the versions of the packages mentioned in the
patch.


> One potential problem I see, is if a tag is added to a version in
> stable. Since the tag is considered to be added to all newer releases of
> the package the tag will also be assigned to the unstable version, which
> _might_ be not valid anymore. If this turns out to be an issue, we could
> forbid propagation of tags for stable to newer versions.

This is, interestingly, rather easy to do:

 1. Take the history of all the tag patches we have received, in
    submission order
 2. Split it obtaining the history of the tag patches for every single
    package
 3. For every patch in the package tag history, get the associated
    package version.
 4. Sort the packages by package version using a stable sort that will
    guarantee that patches for packages with the same version will still
    be sorted in submission order
 5. Replay the patch sequence that you obtained.

This should make it so that if a tag has been changed in an old version
and has never been changed again in a newer version, then it will stay
in the new version as well.

I do keep the complete submission history already: once we will collect
and store the package versions, this is a smart merge algorithm we could
use.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20070208/1996eeee/attachment.pgp