Crossing debtags and popcon

[Andrea Bolognani]

On Thu, 8 Feb 2007 22:15:50 +0100
Enrico Zini <enrico at enricozini.org> wrote:

> On Sun, Feb 04, 2007 at 11:56:52AM +0100, Andrea Bolognani wrote:
>
> > > In principle these are objectives we should be working towards, but
> > > pardon me if I don't hold my breath waiting for them to be realised.
> > I didn't say it would be easy or quick.
>
> If it's not easy and quick I'm not spending time on it, because before
> I would have finished building it, the nature of the problem I'm trying
> to solve will already have changed.

This doesn't seem like a rational approach.
Some thing just take time to be done, and avoiding that kind of things is
obviously not going to solve the problem.

> > The problems in getting the Package file in sync will disappear as soon as
> > we get dpkg to support tags; the problem of having wrong tags in the Package
> > file is a different, harder to fix, one.
>
> dpkg will never support tags, and has no reason to support tags: dpkg
> only needs to install and deinstall packages, and tags are not involved.

dpkg supports other meta-data that is in no way related to simple package
installation and removing.
The "section" itself, which debtags is superseeding, is at the dpkg level.

Of course dpkg will never be able to perform searches based on tags or
similar, but it should at least *know* about tags existence.

> > > > Or to file a bug against the package having wrong tags.
> > > That _is_ filing a bug.  Wishlist bugs without a patch are much more
> > > likely to be ignored.
> > I was talking about wishlist bugs with a patch, of course.
>
> It's not my intention to start flooding the BTS with bugs about tags:
> that'll mean bug mass filing in case of reorganisations, bugs not
> getting fixed because it's minor and the maintainer doesn't care,
> arguing with the maintainer if the bug is really a bug...

What about this -- the maintainer declares a Tags: field in the control file
only if he intends to manage the tags himself; otherwise, tags are overridable
by someone caring more than him.

> The experiment I ran with tags in the packages file has left me with
> mixed feelings about continuing that or not.  Some maintainers did it
> definitely wrongly, and I haven't bothered filed bugs, but just wrote a
> tiny script that fixes their tags before merging with the other tag
> data.

If you don't tell someone he's doing something the wrong way, how can he stop
doing it?

> Now I'm asking myself if I shouldn't just discontinue tags in control
> files, especially since the web interface now is good both for
> maintainers and for me when reviewing.
>
> Tags in control files can be used to have versioned tags for the
> packages; however, for that to work we have to assume that maintainers
> will put the right tags in the control file, and I've decided to design
> the system with the assumption that this will never happen.

I don't think it's a fair assumption.
A better assumption is that a maintainer that cares for tags and decides to
tag his packages himself, will probably put the right tags at the end.

This could be improved if there was more documentation on tagging packages.

> http://en.wikipedia.org/wiki/Five_laws_of_library_science
>
> These laws work just as well if you substitute books->packages and
> reader->user.
>
> In particular, the 5th: "The library is a growing organism." guarantees
> us that the vocabulary will *always* be subject to small or big
> modifications.

Everything in Debian is subject to small or big modifications -- think about
debhelper compat levels, or policy revisions -- but maintainers seems to be
able to cope with that.

--
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/20070210/ecd57dbc/attachment.pgp