<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>