On Thu, 2009-04-30 at 12:11:04 +0200, Raphael Hertzog wrote: > On Thu, 30 Apr 2009, Guillem Jover wrote: > > 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 that idea. It's not a big deal to have to use a recent dpkg-dev, > there aren't so many users of custom fields...
Right, I agree it's no big deal if it's going to be used privately. Although I still find the X- usage confusing by overloading its current meaning. And I don't think it would be a good idea to for example output a Private-Field from XPB-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). > > It's a bit too verbose for me but I could live with that. :) Yeah, it's a bit verbose but I don't think that should be a problem, if you or someone else has a shorter and clear name proposal we could use instead, that'd be great. Otherwise if you don't mind I'd like to change the code in dpkg-deb to ignore ‘Private-’. regards, guillem -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
