Re: Redundant fields in debian/upstream/metadata and possible lintian check
Hi Charles,
On Sun, May 27, 2018 at 04:46:10PM +0900, Charles Plessy wrote:
> thans for raising the issue. In brief, there have been unsuccessful
> experiments, but I think that we should let people experiment.
Sure. May be without this experiment we would not yet have an
established way for scientific references. So your initial
experiment is really appreciated and had great consequences.
> Le Wed, May 23, 2018 at 03:39:44PM +0200, Andreas Tille a écrit :
> >
> > at least in scientific packages the file debian/upstream/metadata is
> > frequently used since it is the established way to specify citations
> > belonging to some software.. The definition of the fields is given in
> > Wiki[1].
>
> Side note: while in practice, multiple people are subscribed to
> notifications of changes of this page, which means that non-consensual
> additions would be quickly spotted, I think that it would be good to
> clearly mark which fields are broadly used and accepted, and which are
> more experimental or anectodical.
+1
> > These data are gathered in UDD[2]. When I inspected the log of the UDD
> > importer I noticed that there are a lot of redundant fields like
> > "Homepage" or "Watch" where we agreed that these fields should not be
> > duplicated in upstream/metadata.
>
> Indeed, I was hoping that they could in the long term supersede the
> Homepage field of debian/control and the debian/watch file, but it is
> not going to happen anytime soon.
It might be considered as one of several failed attempts to keep
upstream information out of the default packaging files.
> I think that it would have been nice
> to be able to propagate updates of this information to the Debian
> infrastructure without doing a package upload, but...
It can be propagated to UDD - so its half way there.
> I guess that
> somebody else will eventually find a better way to do this.
+1
> > There are also typos and freely invented Fields which are not
> > specified on Wiki[1] (like Distributor', 'CRAN', 'Wiki'). I think it
> > makes sense to have some lintian check for this undefined fields. I
> > think I'll file a wishlist bug about this soon.
>
> I think that it is important to let people experiemnt and introduce new
> fields. Nevertheless, typos and fields with too similar names should be
> prevented.
Yes, experiments are perfectly welcome but lintian warnings will not
prevent experimenting.
> Maybe a Lintian check could send a warning for any field
> that has an edit distance of 1 compared with all the "broadly used
> and accepted" fields ?
I have no idea about lintian - so I don't know whether this is to
complex.
> > However, before I do I'd like to discuss the fields Name and Contact.
> > DEP8 defines[3] the fields Upstream-Name and Upstream-Contact which are
> > the same values in a file that has a high probability to be properly
> > maintained.
>
> (You mean DEP 5).
Yes.
> Since the upstream contact address is volatile, I
> think that ideally it would be better placed in the upstream/metadata
> file. But that may require a change of Policy and other potentially
> very painful discussions...
Good point.
> > In the case of r-* packages from CRAN or Bioconductor it can be even
> > automatically updated (via dh-update-R ... its actually not really
> > done but I think this could be implemented easily - dh-make-R at least
> > generates the fields at the time of initial package creation).
> >
> > I wonder whether we should maintaining duplicated information and thus
> > would like to hear your opinion about orphaning these fields in
> > debian/upstream/metadata.
>
> Homepage and Watch were already removed from the wiki page some time
> ago, but could come back into an "actively deprecated" list of fields.
>
> I think that any duplication done by hand for a long time is going to
> create noise and cost time. But duplications made by automation tools
> such as dh-update-R are potentially useful and sould be more considered
> as "synchronisations" which propagate information from external source
> into the Debian infrastructure.
In any case we should have one source of information - I do not mind
about automatic propagation of it by some tool. For the moment I think
the removal of these redundant files is a sensible way to go. If we
consider automatic updates this can be done in a consitent way.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: