[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

On Sun, Jan 31, 2016 at 08:23:11AM +0100, Andreas Tille wrote:
> Hi,
> over time I have seen several changes in the values we should put in to
> Vcs-* fields.  The latest one is s/http:/https:/.  While using config
> model editor helps a lot to follow those changes we will probably see
> more and more packages inside the archive that never changed but start
> accumulating more and more lintian issues about wrong Vcs fields.
> I wonder whether we are doing the right thing by specifying full URLs in
> debian/control files.  I know that the assumption that packages are
> maintained on Alioth is not fully true but if it would we could use
>    Vcs-Type: {Git|Svn|...}
>    Vcs-Path: <team>/<path_to_pkg_in_team>
> The values Vcs-{Git|Svn|...} and Vcs-Browser could be perfectly
> calculated from the above values and the calculation algorithm could be
> adapted to any change that might be decided upon.  That way a control
> file would stay valid (as long as the package does not move around and
> thus touched anyway).
> To solve the issue that this would not work for packages maintained
> outside Debian infrastructure we could add
>    Vcs-Debian: {yes|no}
> or alternatively
>    Vcs-Host: debian.org
> or something like this.  If these are set Vcs-Type + Vcs-Path become
> valid.
> What do you think?

Yes, it makes sense
to have a both Vcs-{Git|Svn|...} and a separate Vcs-Browser field.

Keep the possibility to copy-and-paste an VCS-URL for "manual checkout"

Keep a working Vcs-Brower URL. Because:
 * site admin is allowed to configure prefered "HTTP VCS Viewer"
 * user/humans/developers have a URL that can be used without extra adding / fiddling.

So no need to put extra code in `debcheckout` that does magic/voodoo
with headers like 'Vcs-Debian' and 'Vcs-Host'.

Geert Stappers
The packaging system is not for distribution, but for collaboration.
(Quoting Martin Michylmaier, FOSDEM 2016-01-30, quoting Ian Murdock, 2004)

Attachment: signature.asc
Description: Digital signature

Reply to: