<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, 7 Sep 2015 at 03:36 Luca Bruno <<a href="mailto:lucab@debian.org">lucab@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
this is a brainstorming mail, mostly to Angus (who planned the initial split)<br>
and to everybody else for comments.<br></blockquote><div><br></div><div>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 ;)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My question is: do we specifically need hashes in binary package name?<br>
Corollary is: can we rename libstd-rust-deadbeef to libstd-rust-1.x<br>
(at some point in the future)?<br></blockquote><div><br></div><div>The TL;DR is "No, we don't specifically need hashes in the binary package name".</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We partially touched this topic in the discussion about nightlies.<br>
It is my understanding that we are using the hash in package name to mimic<br>
some kind of soname matching, but anyway we have overrides in place to keep<br>
lintian happy and we don't really have C-style transitions.<br></blockquote><div><br></div><div>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(*).</div><div><br></div><div>(*) 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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As such, I wonder if we can just swap the hash with the full version in future<br>
revisions, or if there are some corner-cases I'm not seeing.<br></blockquote><div><br></div><div>Challenges:</div><div><br></div><div>- I don't think we can rename the actual library _files_ to use numeric versions. "libstd-<span style="color:rgb(0,0,0);font-family:monospace">62abc69f</span>.so" is unlikely to conflict with any other library, but "<a href="http://libstd-1.2.0.so">libstd-1.2.0.so</a>" 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).</div><div><br></div><div>- 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.</div><div>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 "<a href="http://libfoo-rust1.2.so">libfoo-rust1.2.so</a>", but then downstream dependencies of *that* need to do the same again (<a href="http://libbar-libfoo3.4-rust1.2.so">libbar-libfoo3.4-rust1.2.so</a>), etc, etc. Iow, replacing the hash function with "strcat" certainly works, but it gets unwieldy.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As an additional point for discussion, given that we are not strictly bound by<br>
soname, we could think about keeping the same package name when uploading beta<br>
channel to experimental and later for stable release.<br></blockquote><div><br></div><div>I think this suggestion is highly hazardous and we should take steps to make it impossible.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>(+) <a href="http://doc.rust-lang.org/1.1.0/rustc_back/svh/index.html">http://doc.rust-lang.org/1.1.0/rustc_back/svh/index.html</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I still have mixed feeling on all of this, as I see both pros and cons:<br>
+ hash-less package names seem friendlier for users<br>
- hash-ed names directly match with content<br>
+ we could speed up NEW-queuing by uploading betas to experimental, earlier<br>
+ we can reduce the number of trips through NEW<br>
- hashes will change between betas/stable, but package name won't<br>
(BUT hash changes will only happen in betas, which will only hit experimental)<br></blockquote><div><br></div><div>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).</div><div><br></div><div>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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+ at the moment, only rustc needs to known about hashes, sysroot, etc.<br>
(rust won´t have ABI stability for some time)<br>
<br>
Your comments?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div> - Gus</div></div></div>