<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hello,<br>
<br>
Are we ready to do that?<br>
<br>
Thanks<br>
S<br>
<br>
Le 07/09/2015 04:01, Angus Lees a écrit :<br>
</div>
<blockquote
cite="mid:CAPA_H3eP676CP64DcArwEYyMB2EzGht2PQXU3COfWA64+Ja-_w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Mon, 7 Sep 2015 at 03:36 Luca Bruno <<a
moz-do-not-send="true" href="mailto:lucab@debian.org"><a class="moz-txt-link-abbreviated" href="mailto:lucab@debian.org">lucab@debian.org</a></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
moz-do-not-send="true" 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
moz-do-not-send="true" href="http://libfoo-rust1.2.so">libfoo-rust1.2.so</a>",
but then downstream dependencies of *that* need to do the
same again (<a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Pkg-rust-maintainers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pkg-rust-maintainers@lists.alioth.debian.org">Pkg-rust-maintainers@lists.alioth.debian.org</a>
<a class="moz-txt-link-freetext" href="https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers">https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers</a>
</pre>
</blockquote>
<br>
</body>
</html>