[Pkg-rust-maintainers] Removing hash from binary package name
sylvestre at debian.org
Mon Nov 9 12:28:56 UTC 2015
Are we ready to do that?
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
> (*) 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.
> - 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
> + 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,
> (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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pkg-rust-maintainers