On Wed, 2009-06-24 at 00:17 -0400, Jonathan Yu wrote: > >> > >> Should this be something in the policy itself? > > > > I think so. But in general Policy doesn't document every possible > > field, only the ones with Policy significance. dpkg from time to time > > adds additional informational fields without needing a Policy section > > first. However, I think that ones that become established should gain > > Policy documentation so that we can be sure of interoperability, like we > > did with Homepage. > > For me it just seems odd to add fields to d/control that aren't in > policy, though your explanation makes sense to me.
Not at all. There is experimentation in advance of acceptance in this
case, and I really don't believe that the overhead of sending every
wacky proposal through policy before allowing it to be in the control
file would not help the development of new features.
> > proposed specification. For Lintian, we had trouble finding
> > documentation for what the contents should be for some cases,
> > particularly Vcs-Mtn.
> >From the Developer's Reference, Vcs-Mtn refers to the mtn (Monotone)
> version control system.
>
> I don't really think that each version control system should have its
> own field, like Vcs-Mtn, Vcs-Svn, Vcs-Git etc, because it's simply not
> very future proof in my opinion. On the other hand we've got
> situations where there are lots of Version Control systems that use
> HTTP and WebDAV (like SVN via http://) so it's hard to detect what
> type of repository something is simply given the URL.
I tend to agree, though in reality we essentially do have a two-part
identifier, and if we define it as such there is no reason why we can't
say that the field is 'Vcs-' + vcs-type + ':' + vcs-url, and future
proof it by allowing the list of vcs-types to be defined outside of
policy.
> It looks like the intent of having several fields for different Vcs
> mechanisms is that you can put several systems per package. So if you
> maintain your package in Svn and Git, you could have Vcs-Svn and
> Vcs-Git repositories for that.
Indeed. And it might be possible to have mirrors defined, too, where the
type is the same.
> It seems like it's reached the point where it's an ad-hoc standard and
> I think that makes it a reasonable candidate for inclusion into Debian
> Policy, though this might mean hammering out a clearer standard.
Yes, I agree, it seems to be fairly actively used, and is probably time
to review the current design and put something into policy.
Cheers,
Andrew.
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Fine day to work off excess energy. Steal something heavy.
------------------------------------------------------------------------
signature.asc
Description: This is a digitally signed message part
