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

[Sylvestre Ledru]

Hello,

Are we ready to do that?

Thanks
S

Le 07/09/2015 04:01, Angus Lees a écrit :
> On Mon, 7 Sep 2015 at 03:36 Luca Bruno <lucab at debian.org
> <mailto: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 <http://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 <http://libfoo-rust1.2.so>", but
> then downstream dependencies of *that* need to do the same again
> (libbar-libfoo3.4-rust1.2.so <http://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
>
>
> _______________________________________________
> Pkg-rust-maintainers mailing list
> Pkg-rust-maintainers at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers

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