Package: ftp.debian.org Severity: wishlist Hello,
Stage 1 (core of this wishlist bug): referring to my proposal in [email protected][1], I'd like to ask to change the handling of the "Tag:" field overrides: instead of replacing the field in the packages, it should just add the field when it is missing, and ignore the override if the Tag: field already exists in the package. That would allow maintainers to take charge of tag maintenance if they so desire, and it would allow to have different tags in different versions of a package in those rare case it is needed, like package renames (e.g. git is a completely different thing in lenny and squeeze). This is not intended to be the preferred way of handling tags, but just a way to handle corner cases. A maintainer adding Tag: fields to debian/control takes full responsibility for keeping them up to date. On the other hand one can always remove the Tag: fields to hand back tag maintenance to the normal workflow, once the corner case for a specific version has been handled. [1] http://lists.alioth.debian.org/pipermail/debtags-devel/2012-January/002158.html Stage 2 (possible future directions): At Debconf in Banja Luka we discussed a more complex proposal of having tags from some facet take priority from debian/control, and some take priority from the overrides. That went in the direction of making some tags official and leave some 'unstable' facets the ability to change without requiring package uploads. That proposal can be implemented on top of this one, by implementing a "$DEFAULTS" placeholder that maintainers can add to the Tag: field, meaning "dak, please replace this with Enrico's tags for facets not show here". Some examples (to be used in binary package sections of debian/control): # This would be the equivalent of not having a Tag: field. All tags # come from the overrides from debtags.debian.net. Tag: $DEFAULTS # This would use those 3 tags, plus all tags from the overrides that # do not start with "implemented-in::" or "role::" Tag: implemented-in::c, implemented-in::python, role::program, $DEFAULTS # This would only use those 3 tags, ignoring the overrides Tag: implemented-in::c, implemented-in::python, role::program I understand that stage 2 is tricker to implement than stage 1 and probably requires more discussion[1], but in filing a wishlist bug I wanted to provide some context and a possible vision on where the field could be going in the future. [1] Do we need to handle spurious/missing commas around $DEFAULTS? Can we finally get rid of compressing the Tag: header with curly braces, and just have dak make it a multiline field if it is too long? Ciao, Enrico -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
