Reusing source package name of long-removed, unrelated package

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

Reusing source package name of long-removed, unrelated package

Gard Spreemann-2
Hello,

I filed an ITP (#920912) regarding a package I'm preparing. The upstream
name for this package is "phat", which doesn't appear in the archives
from jessie to the present day. After filing the ITP and uploading my
package to mentors, I realized that there was an unrelated "phat" with a
different upstream present in the archives from 2005 to 2014 [1]. It was
removed from the archives because it was abandoned by upstream
(#751276).

I understand that 3.3.2 of the policy mandates that I at least bump the
epoch, but I wanted to ask the list to make sure: is reusing the source
package name of an unrelated, long-removed package like this OK, or
should I consider using a different name?


[1] https://tracker.debian.org/pkg/phat


 Best regards,
 Gard

Reply | Threaded
Open this post in threaded view
|

Re: Reusing source package name of long-removed, unrelated package

Ian Jackson-2
Gard Spreemann writes ("Reusing source package name of long-removed, unrelated package"):
> I filed an ITP (#920912) regarding a package I'm preparing. The upstream
> name for this package is "phat", which doesn't appear in the archives
> from jessie to the present day. After filing the ITP and uploading my
> package to mentors, I realized that there was an unrelated "phat" with a
> different upstream present in the archives from 2005 to 2014 [1]. It was
> removed from the archives because it was abandoned by upstream
> (#751276).

Hrm.

> I understand that 3.3.2 of the policy mandates that I at least bump the
> epoch, but I wanted to ask the list to make sure: is reusing the source
> package name of an unrelated, long-removed package like this OK, or
> should I consider using a different name?

I would recommend using a different source package name.  As two
examples of things that might go wrong:

There are utilities that will download all revisions of a particular
package from snapshot.d.o and make them into a combined history.  Such
a utility would unify the history of your package and the unrelated
prior package - unless it had some kind of ad-hoc and unreliable
heuristic, perhaps.

Someone who searches for archived bugs for your source package will
find their search results contain bugs for the previous package of the
same name.

Also, using a different name means you do not need to use an epoch,
which is (in a small way) nicer.

HTH.

Regards,
Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: Reusing source package name of long-removed, unrelated package

Gard Spreemann-2

Ian Jackson <[hidden email]> writes:

> Gard Spreemann writes ("Reusing source package name of long-removed, unrelated package"):
>> I understand that 3.3.2 of the policy mandates that I at least bump the
>> epoch, but I wanted to ask the list to make sure: is reusing the source
>> package name of an unrelated, long-removed package like this OK, or
>> should I consider using a different name?
>
> I would recommend using a different source package name.

Thanks for your input. I'll wait a bit and see if there are other
opinions before renaming the source.

By the way, is it OK if the (renamed) source package produces a binary
package with the same name as one of those produced by the old source?

Thanks.

 Best,
 Gard

Reply | Threaded
Open this post in threaded view
|

Re: Reusing source package name of long-removed, unrelated package

Julien Cristau-6
On 2/6/19 4:31 PM, Gard Spreemann wrote:

>
> Ian Jackson <[hidden email]> writes:
>
>> Gard Spreemann writes ("Reusing source package name of long-removed, unrelated package"):
>>> I understand that 3.3.2 of the policy mandates that I at least bump the
>>> epoch, but I wanted to ask the list to make sure: is reusing the source
>>> package name of an unrelated, long-removed package like this OK, or
>>> should I consider using a different name?
>>
>> I would recommend using a different source package name.
>
> Thanks for your input. I'll wait a bit and see if there are other
> opinions before renaming the source.
>
> By the way, is it OK if the (renamed) source package produces a binary
> package with the same name as one of those produced by the old source?
>
I would say reusing binary package names is usually worse than reusing
source package names, in that it's a lot more likely to affect users.
Sometimes it happens anyway, but IMO it's best avoided.

Cheers,
Julien

Reply | Threaded
Open this post in threaded view
|

Re: Reusing source package name of long-removed, unrelated package

Jeremy Bicha-5
In reply to this post by Gard Spreemann-2
On Wed, Feb 6, 2019 at 5:39 AM Gard Spreemann <[hidden email]> wrote:
> I understand that 3.3.2 of the policy mandates that I at least bump the
> epoch, but I wanted to ask the list to make sure: is reusing the source
> package name of an unrelated, long-removed package like this OK, or
> should I consider using a different name?

You don't need to bump the epoch since your package has a higher
version number than the old package.

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

Recreating history of a package (was: Re: Reusing source package name of long-removed, unrelated package)

Carsten Leonhardt
In reply to this post by Ian Jackson-2
Ian Jackson <[hidden email]> writes:

> There are utilities that will download all revisions of a particular
> package from snapshot.d.o and make them into a combined history.

Would you care to name those you know of? I have been searching for
something like that but I didn't find anything useful.

Regards,

Carsten

Reply | Threaded
Open this post in threaded view
|

Re: Recreating history of a package

Carsten Schoenert
Am 06.02.19 um 17:59 schrieb Carsten Leonhardt:
> Ian Jackson <[hidden email]> writes:
>
>> There are utilities that will download all revisions of a particular
>> package from snapshot.d.o and make them into a combined history.
>
> Would you care to name those you know of? I have been searching for
> something like that but I didn't find anything useful.

I know of at least git-buildpackage will do this with the option
'--import-dscs' by importing all available versions from the Debian
archives.

I assume Ian's tool can do something similar.

--
Regards
Carsten Schoenert

Reply | Threaded
Open this post in threaded view
|

Re: Recreating history of a package (was: Re: Reusing source package name of long-removed, unrelated package)

Roberto C. Sánchez-2
In reply to this post by Carsten Leonhardt
On Wed, Feb 06, 2019 at 05:59:40PM +0100, Carsten Leonhardt wrote:
> Ian Jackson <[hidden email]> writes:
>
> > There are utilities that will download all revisions of a particular
> > package from snapshot.d.o and make them into a combined history.
>
> Would you care to name those you know of? I have been searching for
> something like that but I didn't find anything useful.
>
Use 'gbp import-dscs' with the --debsnap option.

Regards,

-Roberto

--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

Re: Reusing source package name of long-removed, unrelated package

Ian Jackson-2
In reply to this post by Julien Cristau-6
Julien Cristau writes ("Re: Reusing source package name of long-removed, unrelated package"):
> I would say reusing binary package names is usually worse than reusing
> source package names, in that it's a lot more likely to affect users.
> Sometimes it happens anyway, but IMO it's best avoided.

To an extent that depends how many people are likely to have had the
previous binary package installed, still, and where it might be
referred to (eg in dependencies).  So the problem with reusing a
binary package name becomes less severe, the longer the gap between
the two uses of the name.

Also it is more important that the binary package is easily
discovrable or even guessable.

So I think it's more of a tradeoff than with a source package name:
reusing a source package name is IMO almost never (maybe never at all)
the right idea.  I think reusing a binary package name is sometimes
better than picking a new name.

To Gard: waiting for a few more opinions and then deciding is a good
plan.

Regards,
Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: Reusing source package name of long-removed, unrelated package

Jeremy Stanley
On 2019-02-06 21:15:38 +0000 (+0000), Ian Jackson wrote:
[...]
> reusing a source package name is IMO almost never (maybe never at
> all) the right idea.
[...]

To take an example, I maintain the weather-util packages in main.
The weather-util binary package provides a /usr/bin/weather
executable because upstream calls the project "weather" but a
release or so before I packaged it there was a game in non-free with
a source package named weather which had been orphaned and
subsequently removed. Rather than deal with the confusion I opted to
just call my source package weather-util and named its main binary
package the same, even though I could technically per policy have
used weather for one or both of them (the previous weather source
package didn't even create a binary package of the same name, if
memory serves, so no transitional period would have been required).
More than a dozen years have passed, and this choice really hasn't
presented a problem whatsoever.
--
Jeremy Stanley

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

Re: Recreating history of a package (was: Re: Reusing source package name of long-removed, unrelated package)

Peter Pentchev
In reply to this post by Roberto C. Sánchez-2
On Wed, Feb 06, 2019 at 12:34:22PM -0500, Roberto C. Sánchez wrote:

> On Wed, Feb 06, 2019 at 05:59:40PM +0100, Carsten Leonhardt wrote:
> > Ian Jackson <[hidden email]> writes:
> >
> > > There are utilities that will download all revisions of a particular
> > > package from snapshot.d.o and make them into a combined history.
> >
> > Would you care to name those you know of? I have been searching for
> > something like that but I didn't find anything useful.
> >
> Use 'gbp import-dscs' with the --debsnap option.
...which happens to use the debsnap(1) tool from the devscripts package.

(debsnap(1) was one of the tools that I only learned about because of
 the "dpkg -L devscripts | grep bin/ | shuf -n10" question in
 the NM templates; many thanks to whoever added this one - and this
 goes for both the tool and the NM question :))

G'luck,
Peter

--
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} [hidden email]
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

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

Re: Recreating history of a package

Jonathan Dowland
In reply to this post by Carsten Schoenert
On Wed, Feb 06, 2019 at 06:32:02PM +0100, Carsten Schoenert wrote:
>I know of at least git-buildpackage will do this with the option
>'--import-dscs' by importing all available versions from the Debian
>archives.
>
>I assume Ian's tool can do something similar.

To be explicit, that's "dgit"
https://packages.debian.org/sid/dgit

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

Re: Reusing source package name of long-removed, unrelated package

Gard Spreemann-3
In reply to this post by Ian Jackson-2

Ian Jackson <[hidden email]> writes:

> Julien Cristau writes ("Re: Reusing source package name of long-removed, unrelated package"):
>> I would say reusing binary package names is usually worse than reusing
>> source package names, in that it's a lot more likely to affect users.
>> Sometimes it happens anyway, but IMO it's best avoided.
>
> To an extent that depends how many people are likely to have had the
> previous binary package installed, still, and where it might be
> referred to (eg in dependencies).  So the problem with reusing a
> binary package name becomes less severe, the longer the gap between
> the two uses of the name.

FWIW, popcon suggests the number of users declined steadily after the
removal, and has now plateaued at 15 [1].

> To Gard: waiting for a few more opinions and then deciding is a good
> plan.

Will do. Thanks for your feedback so far, everyone.

[1] https://qa.debian.org/popcon.php?package=phat


 Best,
 Gard

Reply | Threaded
Open this post in threaded view
|

Re: Reusing source package name of long-removed, unrelated package

Gard Spreemann-2
In reply to this post by Ian Jackson-2
(Apologies if you receive this message twice; I dropped a ball juggling
e-mail identities).

Ian Jackson <[hidden email]> writes:

> Julien Cristau writes ("Re: Reusing source package name of long-removed, unrelated package"):
>> I would say reusing binary package names is usually worse than reusing
>> source package names, in that it's a lot more likely to affect users.
>> Sometimes it happens anyway, but IMO it's best avoided.
>
> To an extent that depends how many people are likely to have had the
> previous binary package installed, still, and where it might be
> referred to (eg in dependencies).  So the problem with reusing a
> binary package name becomes less severe, the longer the gap between
> the two uses of the name.

FWIW, popcon suggests the number of users declined steadily after the
removal, and has now plateaued at 15 [1].

> To Gard: waiting for a few more opinions and then deciding is a good
> plan.

Will do. Thanks for your feedback so far, everyone.

[1] https://qa.debian.org/popcon.php?package=phat


 Best,
 Gard

Reply | Threaded
Open this post in threaded view
|

Re: Recreating history of a package

Ian Jackson-2
In reply to this post by Jonathan Dowland
Jonathan Dowland writes ("Re: Recreating history of a package"):
> On Wed, Feb 06, 2019 at 06:32:02PM +0100, Carsten Schoenert wrote:
> >I know of at least git-buildpackage will do this with the option
> >'--import-dscs' by importing all available versions from the Debian
> >archives.
> >
> >I assume Ian's tool can do something similar.
>
> To be explicit, that's "dgit"
> https://packages.debian.org/sid/dgit

Thanks for the plug.  Obviously dgit is absolutely the best thing
since sliced bread, will automatically fix all bugs for you, and will
even make you a cup of tea when it's done. [1]

However, it does not yet have a convenient feature to import the
entire history of a particular source package.


Unfortunately gbp import-dscs produces a patches-unnplied history, so
it's not really the same.  Right now if you wanted a dgitish dsc
import, you would:
 1. use debsnap to download all the .dsc's from snapshot.d.o
 2. for f in `/bin/ls ../blah_*.dsc | sort -V`; do
       dgit import-dsc $f ..import-branch
    done
NB that this rune will go wrong if the package has an epoch.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793429
is the wishlist bug relating to this feature.

Implementing that has not been a high priority given that anyone who
wants to do this has to download an insane amount of stuff from
snapshot.d.o, which seems like a bigger barrier to doing this than the
need to do some shell rune like above.  But, nowadays dgit import-dsc
(which postdates #793429) can do most of the hard work, so if someone
feels like writing this feature for dgit, patches would be welcome.

Alternatively if one wanted to get more sophisticated than just
importing every version from snapshot in version number order, one
might write something to look inside the package at the changelogs to
try to discern the branch structure.  I think the Launchpad folks have
some code which can do this.

Ian.

[1] Caution: may not be true.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: Recreating history of a package

peter green-2
In reply to this post by Carsten Schoenert
> Alternatively if one wanted to get more sophisticated than just
> importing every version from snapshot in version number order, one
> might write something to look inside the package at the changelogs to
> try to discern the branch structure.
https://github.com/plugwash/autoforwardportergit/blob/master/pooltogit will take dscs in a pool structure and import them into git repos (one per source package) using dgit, building the history based on the changelogs. It can even follow history across source package renames.

It also has the ability to use snapshotsecure to download parent versions from snapshot.debian.org , As the code stands it only uses that functionality to request immediate parents of local versions, but it could be easily modified to grab the entire history of the package (as defined by it's changelog).

Reply | Threaded
Open this post in threaded view
|

Re: Recreating history of a package

Ian Jackson-2
peter green writes ("Re: Recreating history of a package"):
> https://github.com/plugwash/autoforwardportergit/blob/master/pooltogit will take dscs in a pool structure and import them into git repos (one per source package) using dgit, building the history based on the changelogs. It can even follow history across source package renames.
>
> It also has the ability to use snapshotsecure to download parent versions from snapshot.debian.org , As the code stands it only uses that functionality to request immediate parents of local versions, but it could be easily modified to grab the entire history of the package (as defined by it's changelog).

Cool, thanks!  Have you considered making a package of it ?

Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: Recreating history of a package

peter green-2
On 12/02/19 13:26, Ian Jackson wrote:
> peter green writes ("Re: Recreating history of a package"):
>> https://github.com/plugwash/autoforwardportergit/blob/master/pooltogit will take dscs in a pool structure and import them into git repos (one per source package) using dgit, building the history based on the changelogs. It can even follow history across source package renames.
>>
>> It also has the ability to use snapshotsecure to download parent versions from snapshot.debian.org , As the code stands it only uses that functionality to request immediate parents of local versions, but it could be easily modified to grab the entire history of the package (as defined by it's changelog).
> Cool, thanks!  Have you considered making a package of it ?
In it's present form it is specialized to the needs of autoforwardportergit, so packaging it separately (if/when I get around to packaging autoforwardportergit it will be packaged as part of that) in it's present form doesn't make much sense. It would certainly be possible to generalize it, but that would require thought/decisions on how best to do that.

Thinking more about the possibility of importing the entire history of a source package it is more problematic than my off the cuff reply implied. It would be easy to modify pooltogit to try to retrieve the entire history, but for a large proportion of packages this would result in a failure to import for several reasons.

1. Changelogs sometimes include versions that were never uploaded to Debian. I suspect they also sometimes include versions that were uploaded but were superseded before they made it to a snapshot.
2. Snapshot.debian.org is only offered over plain insecure http. For recent versions the packages can be verified against the Packages/Sources files which can in turn be verified with gpg but older versions are more problematic to verify as the relevant packages/sources files are only signed with 1024 bit keys or not signed at all. This is made worse by the fact that snapshot.debian.org has an API to obtain the first snapshot a package is available in but not any API to find the last snapshot it was available in.
3. Some packages aren't on snapshot.debian.org at all due to age.
4. Some packages are blocked on snapshot.debian.org due to license issues.

Reply | Threaded
Open this post in threaded view
|

Re: Recreating history of a package

Guillem Jover
Hi!

On Sat, 2019-02-16 at 12:22:04 +0000, peter green wrote:
> 2. Snapshot.debian.org is only offered over plain insecure http. For
>    recent versions the packages can be verified against the
>    Packages/Sources files which can in turn be verified with gpg but
>    older versions are more problematic to verify as the relevant
>    packages/sources files are only signed with 1024 bit keys or not
>    signed at all. This is made worse by the fact that
>    snapshot.debian.org has an API to obtain the first snapshot a
>    package is available in but not any API to find the last snapshot
>    it was available in.

http://snapshot.debian.org/ is now offered over https too. Its front-page
even documents its usage as such. :)

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Recreating history of a package

Ben Hutchings-3
On Sat, 2019-02-16 at 14:17 +0100, Guillem Jover wrote:

> Hi!
>
> On Sat, 2019-02-16 at 12:22:04 +0000, peter green wrote:
> > 2. Snapshot.debian.org is only offered over plain insecure http. For
> >    recent versions the packages can be verified against the
> >    Packages/Sources files which can in turn be verified with gpg but
> >    older versions are more problematic to verify as the relevant
> >    packages/sources files are only signed with 1024 bit keys or not
> >    signed at all. This is made worse by the fact that
> >    snapshot.debian.org has an API to obtain the first snapshot a
> >    package is available in but not any API to find the last snapshot
> >    it was available in.
>
> http://snapshot.debian.org/ is now offered over https too. Its front-page
> even documents its usage as such. :)
And it has HSTS, which is nice, but it is missing the redirection
that's needed to make that work completely.

Ben.

--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson



signature.asc (849 bytes) Download Attachment
12