Adam Borowski wrote...
> On Fri, Oct 20, 2017 at 11:42:04AM -0400, Jeremy Bicha wrote:
> > On Fri, Oct 20, 2017 at 10:59 AM, W. Martin Borgert <debacle@debian.org> wrote:
> > > I would package the new dino under this name, because I don't think
> > > there is a conflict.
> >
> > It is a problem for Ubuntu unless the new version has a newer version
> > number than the old package.
> >
> > Launchpad does not forget about old version numbers.
>
> Neither does our PTS for packages in still supported releases, nor BTS ever,
Security tracker, and certainly many more tools that are not on radar.
> nor user machines that still have the extinct dino installed. But that's
> easily fixable by making sure your version number is higher (use an epoch if
> you must).
Surprise to the users if they still use the old package - which they
shouldn't since it has been of support for a long time, but these things
happen.
Another surprise, if they found a recommendation for the old package but
get the new one.
> There is another concern: I'd refrain with reintroduction until at least one
> dino-less release. Oh wait, stretch is already out.
In my opinion: Wait until the old package is burried and forgotten. So the
gap should rather be somewhat ten years.
Or: Never ever re-use a package name. Also: Reject NEW packages with
short names (say, less than six characters) since it's quite likely they
will collide semantically with something else.
Or: Introduce package namespaces, this is a big change. The existing
flat model one with somewhat hundred thousand (wild guess) entries over
the past 25 years worked quite well most of the time, although not
always (git, node). But it's obvious there is a problem in the very long
run, and it seems wise to think about that before it becomes pressing.
For a start, there is the Section: information, then a sound/dino and a
net/dino could co-exist.
Christoph
Attachment:
signature.asc
Description: Digital signature