lintian-brush adds redundant data

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

lintian-brush adds redundant data

Andreas Tille-5
Hi,

I observed that lintian-brush is adding a file debian/upstream/metadata
if it finds the fields Upstream-Name and Upstream-Contact in
debian/copyright.

What is the sense to duplicate data that we can find in a well
established machine readable file in another file?

Kind regards

       Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: lintian-brush adds redundant data

Jelmer Vernooij
Hi Andreas,

On Tue, Aug 20, 2019 at 04:17:50PM +0200, Andreas Tille wrote:
> I observed that lintian-brush is adding a file debian/upstream/metadata
> if it finds the fields Upstream-Name and Upstream-Contact in
> debian/copyright.

> What is the sense to duplicate data that we can find in a well
> established machine readable file in another file?
That's a good question.

I've considered (but not implemented yet) having lintian-brush not create a
debian/upstream/metadata if the only upstream metadata fields it can set are
the name and contact.

At the moment, both the debian/copyright [1] and debian/upstream/metadata [2]
standards both define two fields with (as far as I can tell) the same purpose.
Neither of the standards provide any guidance as to whether the fields
should be set in both files or whether e.g. one is preferred over the other.
It would be great if some guidance could be added to DEP-12 about how to deal
with these fields.

Cheers,

Jelmer

[1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
[2] https://dep-team.pages.debian.net/deps/dep12/

Reply | Threaded
Open this post in threaded view
|

Re: lintian-brush adds redundant data

Andreas Tille-5
Hi Jelmer,

On Tue, Aug 20, 2019 at 04:46:23PM +0000, Jelmer Vernooij wrote:

>
> On Tue, Aug 20, 2019 at 04:17:50PM +0200, Andreas Tille wrote:
> > I observed that lintian-brush is adding a file debian/upstream/metadata
> > if it finds the fields Upstream-Name and Upstream-Contact in
> > debian/copyright.
>
> > What is the sense to duplicate data that we can find in a well
> > established machine readable file in another file?
> That's a good question.
>
> I've considered (but not implemented yet) having lintian-brush not create a
> debian/upstream/metadata if the only upstream metadata fields it can set are
> the name and contact.

It would be really great to implement this.  Considering the current
situation I would even remove the fields Name and Contact from
debian/upstream/metadata if the according fields are in debian/copyright
(or move them if they are missing in d/copyright).  If some empty
d/u/metadata remains this should be removed as well.

IMHO a good rule of thumb is:  Do not copy any data from some well
established machine readable file to some other place.
 
> At the moment, both the debian/copyright [1] and debian/upstream/metadata [2]
> standards both define two fields with (as far as I can tell) the same purpose.
> Neither of the standards provide any guidance as to whether the fields
> should be set in both files or whether e.g. one is preferred over the other.
> It would be great if some guidance could be added to DEP-12 about how to deal
> with these fields.

DEP-12 is declared as "Work in progress" (without any progress since 5
years) while DEP-5 is well established and decided.  Charles and I
invented d/u/metadata to store publication information and it turned out
that there is other sensible information about upstream that can be
stored there as well.  I'd vote against any duplication of information
in any way.  So as long as Name and Contact are defined in DEP-5 it
should not be in DEP-12.

So far I removed redundant fields from the Wiki page[3] (it had also
Homepage, Watch and others I might have forgot) since it simply adds
useless maintenance burden to maintain the same information at different
places.

The idea that lintian is warning about those fields missing in
d/u/metadata is not sensible, neither that some tool adds the values.
It was some Wiki edit away[4] to ensure you about this that this stuff
is really in flux and its better to not waste time on this without
discussing it first.

I'd be really happy if lintian-brush would remove those values (please
let me know if you want me to file a bug report about this).

BTW, in general I really like lintian-brush which does a pretty nice job
and I'll keep on running it even if I do not like the feature above.  So
please keep on the nice work.

Kind regards

      Andreas.
 
> [1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> [2] https://dep-team.pages.debian.net/deps/dep12/

[3] https://wiki.debian.org/UpstreamMetadata
[4] https://wiki.debian.org/UpstreamMetadata#Deprecated_fields

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: lintian-brush adds redundant data

Paul Wise via nm
On Wed, Aug 21, 2019 at 2:48 PM Andreas Tille wrote:

> DEP-12 is declared as "Work in progress" (without any progress since 5
> years) while DEP-5 is well established and decided.  Charles and I
> invented d/u/metadata to store publication information and it turned out
> that there is other sensible information about upstream that can be
> stored there as well.  I'd vote against any duplication of information
> in any way.  So as long as Name and Contact are defined in DEP-5 it
> should not be in DEP-12.

These fields seem like they belong in DEP-12 more than DEP-5.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: lintian-brush adds redundant data

Andreas Tille-2
On Wed, Aug 21, 2019 at 05:47:24PM +0800, Paul Wise wrote:

> On Wed, Aug 21, 2019 at 2:48 PM Andreas Tille wrote:
>
> > DEP-12 is declared as "Work in progress" (without any progress since 5
> > years) while DEP-5 is well established and decided.  Charles and I
> > invented d/u/metadata to store publication information and it turned out
> > that there is other sensible information about upstream that can be
> > stored there as well.  I'd vote against any duplication of information
> > in any way.  So as long as Name and Contact are defined in DEP-5 it
> > should not be in DEP-12.
>
> These fields seem like they belong in DEP-12 more than DEP-5.

Finally that's a matter of taste where the fields belong to.  As long as
there is no decision including a change of DEP-5 and a finalised DEP-12
I'd consider any change as its currently done as premature.

Kind regards

      Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: lintian-brush adds redundant data

Jelmer Vernooij
In reply to this post by Andreas Tille-5
Hi Andreas,

On Wed, Aug 21, 2019 at 08:47:51AM +0200, Andreas Tille wrote:

> On Tue, Aug 20, 2019 at 04:46:23PM +0000, Jelmer Vernooij wrote:
> >
> > On Tue, Aug 20, 2019 at 04:17:50PM +0200, Andreas Tille wrote:
> > > I observed that lintian-brush is adding a file debian/upstream/metadata
> > > if it finds the fields Upstream-Name and Upstream-Contact in
> > > debian/copyright.
> >
> > > What is the sense to duplicate data that we can find in a well
> > > established machine readable file in another file?
> > That's a good question.
> >
> > I've considered (but not implemented yet) having lintian-brush not create a
> > debian/upstream/metadata if the only upstream metadata fields it can set are
> > the name and contact.
>
> It would be really great to implement this.  Considering the current
> situation I would even remove the fields Name and Contact from
> debian/upstream/metadata if the according fields are in debian/copyright
> (or move them if they are missing in d/copyright).  If some empty
> d/u/metadata remains this should be removed as well.
>
> IMHO a good rule of thumb is:  Do not copy any data from some well
> established machine readable file to some other place.
Agreed, having data duplicated in two Debian-specific files seems unnecessary and bad.

> > At the moment, both the debian/copyright [1] and debian/upstream/metadata [2]
> > standards both define two fields with (as far as I can tell) the same purpose.
> > Neither of the standards provide any guidance as to whether the fields
> > should be set in both files or whether e.g. one is preferred over the other.
> > It would be great if some guidance could be added to DEP-12 about how to deal
> > with these fields.
>
> DEP-12 is declared as "Work in progress" (without any progress since 5
> years) while DEP-5 is well established and decided.  Charles and I
> invented d/u/metadata to store publication information and it turned out
> that there is other sensible information about upstream that can be
> stored there as well.  I'd vote against any duplication of information
> in any way.  So as long as Name and Contact are defined in DEP-5 it
> should not be in DEP-12.

> So far I removed redundant fields from the Wiki page[3] (it had also
> Homepage, Watch and others I might have forgot) since it simply adds
> useless maintenance burden to maintain the same information at different
> places.
Thanks for updating the specification.

I think longer term it would actually make sense to put this information in
debian/upstream/metadata rather than debian/copyright, so all upstream metadata
is in one place - but that would obviously require a change to DEP-5 first.

> The idea that lintian is warning about those fields missing in
> d/u/metadata is not sensible, neither that some tool adds the values.
> It was some Wiki edit away[4] to ensure you about this that this stuff
> is really in flux and its better to not waste time on this without
> discussing it first.
>
> I'd be really happy if lintian-brush would remove those values (please
> let me know if you want me to file a bug report about this).

I've implemented this. lintian-brush will attempt to update these
fields in debian/copyright only and remove them from debian/upstream/metadata.

Please let me know if you have any other suggestions.

Cheers,

Jelmer

Reply | Threaded
Open this post in threaded view
|

Re: lintian-brush adds redundant data

gregor herrmann-3
On Thu, 22 Aug 2019 21:46:34 +0000, Jelmer Vernooij wrote:

Hi Andreas and Jelmer,

I agree with everything you've said (and changed in the d/u/m spec
and in lintian-brush), thank you.

Just one remark, partly a note to self:

> > The idea that lintian is warning about those fields missing in
> > d/u/metadata is not sensible, neither that some tool adds the values.
> > It was some Wiki edit away[4] to ensure you about this that this stuff
> > is really in flux and its better to not waste time on this without
> > discussing it first.
> >
> > I'd be really happy if lintian-brush would remove those values (please
> > let me know if you want me to file a bug report about this).
>
> I've implemented this. lintian-brush will attempt to update these
> fields in debian/copyright only and remove them from debian/upstream/metadata.
That means that dh-make-perl and dpt-debian-upstream should also at
least stop adding the Name and Contact fields. I think this makes
sense, we've only added them because they were in the spec and we
already had the data, but they didn't make alot of sense to me (as
duplicates from d/copyright, as you both noted). -- In fact we are
only caring about Repository* and Bug* fields (the former were the
reason why we started to use d/u/m in the first place).

I'll make these changes in the perl tools; I'm just wondering, and
that's why I'm writing a public email :), if other tools and/or other
teams use these fields as well and should be notified. Or, in other
words, I fear that having this change only in some thread on -devel
might not be enough.


Cheers,
gregor, cc'ing the perl list as a start

--
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Rolling Stones: Everlasting

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: lintian-brush adds redundant data

Andreas Tille-5
In reply to this post by Jelmer Vernooij
On Thu, Aug 22, 2019 at 09:46:34PM +0000, Jelmer Vernooij wrote:
>
> I think longer term it would actually make sense to put this information in
> debian/upstream/metadata rather than debian/copyright, so all upstream metadata
> is in one place - but that would obviously require a change to DEP-5 first.

Fully agreed.  Once we have properly decided where to store what that's
perfectly fine.  In your great lintian-brush tool you have proven how
easy the move can be - its just not the right time to do so.
 
> > I'd be really happy if lintian-brush would remove those values (please
> > let me know if you want me to file a bug report about this).
>
> I've implemented this. lintian-brush will attempt to update these
> fields in debian/copyright only and remove them from debian/upstream/metadata.

Thanks a lot.
 
> Please let me know if you have any other suggestions.

I'll happily do so.

Thanks again, Andreas.
 

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: lintian-brush adds redundant data

Andreas Tille-5
In reply to this post by gregor herrmann-3
Hi Gregor,

On Fri, Aug 23, 2019 at 12:47:56AM +0200, gregor herrmann wrote:

> > I've implemented this. lintian-brush will attempt to update these
> > fields in debian/copyright only and remove them from debian/upstream/metadata.
>
> That means that dh-make-perl and dpt-debian-upstream should also at
> least stop adding the Name and Contact fields. I think this makes
> sense, we've only added them because they were in the spec and we
> already had the data, but they didn't make alot of sense to me (as
> duplicates from d/copyright, as you both noted). -- In fact we are
> only caring about Repository* and Bug* fields (the former were the
> reason why we started to use d/u/m in the first place).

Since you speak about notes to yourself:  We should also think about
what fields from d/u/m should be stored in UDD.  Currently the
bibliographic references are stored but since I had no actual use for
other fields these are ignored for the moment.
 
> I'll make these changes in the perl tools; I'm just wondering, and
> that's why I'm writing a public email :), if other tools and/or other
> teams use these fields as well and should be notified. Or, in other
> words, I fear that having this change only in some thread on -devel
> might not be enough.

ACK.  Thanks for that very valid point.

Kind regards

     Andreas.

--
http://fam-tille.de