Re: debian/upstream/metadata: next steps

[Jelmer Vernooij <jelmer@debian.org>]

On Sun, Aug 16, 2020 at 02:17:13PM +0200, Mattia Rizzolo wrote:
> On Sat, Aug 15, 2020 at 01:04:35AM +0000, Paul Wise wrote:
> > I wonder if storing metadata (including Homepage, debian/watch,
> > debian/upstream/*) about the upstream project in the Debian source
> > package is the wrong approach. Upstream metadata can change without
> > any need for the Debian source package to change (like them switching
> > hosting platforms or bug reporting software).
> 
> As usual, I'll have to remind people that this is the usual old topic.
> 
> 
> Just keep in mind that:
>  * we used to have a centralized d/watch overrides in the form of MOLE,
>    but that eventually bitrot and was removed
>  * as Charles Plessy mentioned, there used to be a centralized VCS for
>    DEP-12 stuff, but that was also pretty much abandoned IIRC
>  * people keep talking about moving VCS-*, Maintainer, Uploaders, etc
>    etc out of d/control, and has been doing so for many years.  The only
>    related thing I'm aware of is the possibility of adding an override
>    in vcswatch (which is not possible anymore now after quantz's update
>    to buster, incidentally), which is a relatively new project.  Nobody
>    came forward and did any of the work needed to take Maintainer out of
>    d/control.
> 
> 
> So, IMHO, any further discussion about "is it sensible to keep $this in
> debian source package" is totally pointless until somebody actually
> comes up with a working, maintained, etc solution.

Source packages indeed don't seem like the ideal place for this data,
but because of the points raised by Mattia I wonder if that should be
a separate discussion.

There is a lot of adoption for the current DEP-12 draft in source
packages. It would be useful to at least bless the de-facto
standard and encourage its use (both by tools reading the data and
packagers provide the data). There is value in having this be an
official standard and standardising the fields and their syntax,
regardless of whether we'd want to eventually move this data
elsewhere.

Jelmer