[Pkg-rust-maintainers] Removing hash from binary package name

[Angus Lees]

On Mon, 7 Sep 2015 at 03:36 Luca Bruno <lucab at debian.org> wrote:

> Hi all,
> this is a brainstorming mail, mostly to Angus (who planned the initial
> split)
> and to everybody else for comments.
>

Thanks Luca - I've tried to respond impartially, but I admit I had a
"seriously, there are actual problems elsewhere in the world" expression on
my face as I was writing this - and I think I failed to keep some of that
bias out of my comments below ;)

My question is: do we specifically need hashes in binary package name?
> Corollary is: can we rename libstd-rust-deadbeef to libstd-rust-1.x
> (at some point in the future)?
>

The TL;DR is "No, we don't specifically need hashes in the binary package
name".

We need different versions of libstd-rust to be co-installable (so some
sort of version marker needs to be in the name), and there's a pretty
strong policy/convention of naming the package after the included library
soname.  In this case there's several libraries included, and the library
is libstd-*.so not libstd-rust-*.so, so we're already breaking a strict
interpretation of that policy.

We partially touched this topic in the discussion about nightlies.
> It is my understanding that we are using the hash in package name to mimic
> some kind of soname matching, but anyway we have overrides in place to keep
> lintian happy and we don't really have C-style transitions.
>

I'm not sure exactly what you mean by C-style transitions, but yes, we do
(theoretically) have the same soname migrations every time a new rustc is
released - with the same solutions as any other ABI transition(*).

(*) Basically: Recompile everything affected and upload to unstable.  The
dependency machinery will make sure they all transition to testing in an
atomic group.  Allowing co-installs makes unstable usable during the
overlap - and gives us the option of branching the source package if we
have something that *needs* a different/older version.

As such, I wonder if we can just swap the hash with the full version in
> future
> revisions, or if there are some corner-cases I'm not seeing.
>

Challenges:

- I don't think we can rename the actual library _files_ to use numeric
versions.  "libstd-62abc69f.so" is unlikely to conflict with any other
library, but "libstd-1.2.0.so" sounds like a series of characters that some
other package is likely to also choose at some point.  We _could_ rename
the rlibs (and -dev dylibs) since they have an unusual suffix and are
installed in a rust-specific directory (the rust linker finds them by glob
too, so I think this bit would Just Work).

- We won't be able to swap the hash with the full version for other rust
libraries, so this scheme won't be generalisable beyond libstd.
Consider a hypothetical "libfoo" dylib:  The same upstream source will
produce two different incompatible libraries depending on which
rustc/libstd it was compiled against.  We *could* also change that naming
scheme to "libfoo-rust1.2.so", but then downstream dependencies of *that*
need to do the same again (libbar-libfoo3.4-rust1.2.so), etc, etc.  Iow,
replacing the hash function with "strcat" certainly works, but it gets
unwieldy.

As an additional point for discussion, given that we are not strictly bound
> by
> soname, we could think about keeping the same package name when uploading
> beta
> channel to experimental and later for stable release.
>

I think this suggestion is highly hazardous and we should take steps to
make it impossible.

Rust is free to reorder struct fields, inlines many things, and generally
assumes an awful lot about the consistency of the compilation environment
across crates.  I think it would be very easy to end up with two
similar-but-different versions of rustc that produced subtly incompatible
output, and setting up the packaging to allow a package compiled by a beta
rustc to produce an output package that dpkg _thinks_ is compatible would
be creating a minefield.

I _think_ the Rust "SVH" machinery(+) would make the above an obvious
link-error, so the issue might not be hidden - but this only demonstrates
that the beta+release libraries are not at all compatible.

(+) http://doc.rust-lang.org/1.1.0/rustc_back/svh/index.html

I still have mixed feeling on all of this, as I see both pros and cons:
>  + hash-less package names seem friendlier for users
>  - hash-ed names directly match with content
>  + we could speed up NEW-queuing by uploading betas to experimental,
> earlier
>  + we can reduce the number of trips through NEW
>  - hashes will change between betas/stable, but package name won't
>    (BUT hash changes will only happen in betas, which will only hit
> experimental)
>

When the hash changes between betas/stable, we need to update the packaging
dependencies to reflect those incompatibilities.  I claim this is going to
be harder to maintain than just renaming the packages (and also makes the
beta/stable not co-installable unnecessarily).

>From my email history, I think NEW->unstable took <24h for each of the
rustc 1.1 and 1.2 releases.  Do we really need to speed up NEW-processing
more than that?

 + at the moment, only rustc needs to known about hashes, sysroot, etc.
>    (rust won´t have ABI stability for some time)
>
> Your comments?
>

I think I don't understand the problem we're solving.  As far as I've
followed the conversation, we want the user to be able to go from library
filename to rust version without typing a dpkg command, for a package that
a user will only ever auto-install anyway.  Is there any other motivation
here?  I guess I just don't see why this is something that needs to be
changed at all.

Replacing the version string (in whatever format) between releases could be
scripted trivially, and this would indeed make our lives slightly better.
 (I know I did it last time with perl(1) and rename(1) one-liners.  The
only reason I haven't made the packaging handle it automatically is that it
can't be done with substvars and so debian/control won't just exist where
everyone expects it to be.  A script that gets invoked manually and edits
debian/control in place would be easy however.)

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150907/b3d0502c/attachment.html>