Adam DiCarlo wrote: > Huh. I'll have to play around with this. I would indeed rather use a > field, even a custom field, if possible, since this is really data. > > I'm hearing just go with homepage only, no other data really > needed. I'll make that change. > > > The point was validly raised in a previous thread that using these means > > changing packages twice in the event that dpkg is eventually changed. > > That I don't follow. > > The only nice thing about using the description is that it is already > supported by packages.debian.org, whereas a custom field would > obviously not be supported there.
Colin's point is that if a lot of us modify our control files to use XB-Homepage or whatever, and then Homepage goes into policy as a truely supported field, then we all have to go back and remove the "XB-" from our control files. I think the best way to go ahead is get the field added to dpkg, then we can just start using it and go from there. The policy group prefers to document things that are already in use these days I understand. The dpkg maintainers have to be convinced to add it is all. In the meantime, anyone who doesn't mind revving a package later can get a jump on things with the XB- technique. If we can agree on a field name. While I've seen examples of "Upstream-URL", "Upstream-Homepage", etc., I'm partial to just "Homepage". It indicates clearly that it is a web page, and it indicates what page the url is supposed to point to. It's also a term any use who sees it will immediatly understand. The "Upstream" seems redundant. Get a couple hundred packages using the field consistently and it'll really take care of itself. -- see shy jo
pgpAxwsPAlabD.pgp
Description: PGP signature
