Bug#521810: debian-policy: Document user defined fields starting with X-
Hi!
On Tue, 2009-03-31 at 12:03:09 +0200, Raphael Hertzog wrote:
> On Tue, 31 Mar 2009, Russ Allbery wrote:
> > If you're going to standardize a prefix that's purely for private,
> > internal use and will never, ever be standardized in any fashion, could I
> > convince you (and Nils) to use a prefix other than X-? E-mail has
> > poisoned the well on X-, and now people read it to mean "anything that's
> > not been standardized yet" and tend to use it for things that they do plan
> > to standardize later. They're not all going to read the documentation.
> >
> > For this particular use, how about a prefix of Private- instead? That
> > makes it much more explicit that if you're not the organization adding
> > this, you shouldn't expect to understand it or ever use it.
>
> It sounds weird to me on first sight but I would not mind using another
> prefix. Let's see what Nils and Guillem think. (and others who might care)
I do not like the use of double X- for private use either, I think it's
confusing and somewhat redundant.
We use X- to denote a user defined field, which mostly translates to
fields for which support has not yet been added to dpkg-dev, who does
not know where to output such fields, nor which inheritance rules (e.x.
from source to binary package stanzas) to apply.
I also agree with Raphaël that changing dpkg-dev to not strip the
leading X- would be a bad idea, as I don't think the tools dealing with
binary packages would recognize those fields with the X-. Those tools
could be fixed, but that would also imply needing a rebuild of all
affected packages to strip the X- once it has become official.
Another option could be to add a new modifier, like P(rivate) or
U(ser), to be used like XPBS-Field: which would preserve the X-. But
then you need a new enough dpkg-dev to be able to get that field.
I like (XB-)Private-, it works now, and it's pretty clear about what
it means. If it's going to be used only for internal use, then Private-
should be enough, but if those packages are going to be made public and
used by other distros or derivatives, it might make sense to namespace
them with project or company name to avoid possible collisions, due to
more chances of uncoordination about those additions, so something like
XB-Private-Distro-Field (I guess the same should apply if those
projects or companies add support to their dpkg for those fields,
though, like in Distro-Field).
regards,
guillem
Reply to: