Re: [RFC] Promoting the use of "Homepage:" field in debian/control
On Sat, 22 Sep 2007 08:56:29 +0200, Christian Perrier <bubulle@debian.org> said:
> Quoting Manoj Srivastava (srivasta@debian.org):
>> Actually, policy is usually the last thing that you want to do, in
>> the general case. Policy is usually stable (well, not quite as
>> stable as it has been this year, but work seems to be easing up a
>> trifle, so expect a policy release in a couple of weeks).
>>
>> But the idea is that policy documents mature practice, and only when
>> it is deemed really required. Since so few packages do the Homepage
>> thing, I would much rather see a working design, supported by apt and
>> p.d.o, make any changes or tweaks as are needed; and _then_ we look
>> at policy. If very few packages are using it still, you'll have to
>> start with a MAY or suggests, anyway.
> That was my initial idea: have the policy document after the practice
> became common practice as I remember that you (Manoj, but also often
> aj) often remind that the Policy is more about documenting common
> practice and turning it into 'rules' thanestablishing rules before
> they're really used.
> However, re-reading the part that describes debian/control fields in
> the policy, I noticed that they're describe in the *policy* and not in
> the DevRef.
Right. These are staid, old, boring, unchanging fields; and
maintainers need not expect these to change; and putting them in policy
means that even dpkg can't change the fields drastically fro under the
developers.
However, policy is not exhaustive; and if policy says nothing on
a topic, it means the topic is permitted, not prohibited; so the
Homepage: field can be used by any package without the package falling
foul of policy.
> So, my thought when I proposed to begin with the policy was to have it
> describe that field without making it mandatory (MAY requirement, not
> MUST requirement) so that lintian/linda can point developers to it
> when issuing a warning for the missing field.
> So I roughly propose to:
> - Add an item to "5.3 Binary package control files -- DEBIAN/control":
> - Homepage
> (note the missing "mandatory")
> - Add a level 3 section to 5.6 List of fields: 5.6.x Homepage
> The upstream project home page URL. It should preferably contain and
> http(s) URL linking to a page describing the upstream project with
> access to the project's resources. This is an optional field
This looks like a sound addition to policy. Have you given any
thought to a lintian/linda check? (make sure it is a legal URI,
optionally check to see if it is a valid URL pointing to a real web
page, etc). Yes, I am still trying to thing about machine readable
policy documents :)
> Would this better field for an early integration in the policy or do
> you still recommend that it comes after implementation in aptish tools
> and adoption by "enough" packages (probably following integration in
> lintian/linda)?
Well. When it comes to policy, I am very conservative (I am
still smarting from the /usr/doc transition fiasco). Remember the
X-SVN: field? After we thought it was all decided, arch came up, and we
split the single field into a browser and a repo field; and that came
only after it was implemented, people started using it, and other folks
(arch users, like me) came up with suggestions an changes, and the
fields were changed.
It would have been much harder to do so if we had to wait for
policy to change. (I know, I know. Slow policy changes are at least
partially my fault).
So, while I will not prevent you from going the route you
proposed, if you feel it is the right thing to do, I would still advice
caution. Having said that, I am not sure what changes might be needed
for home page fields (is there a concept like ultiple homepages?), but
I have often found that people have far more imagination than I have.
manoj
--
"It's what you learn after you know it all that counts." John Wooden
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: