<div dir="ltr"><div class="gmail_quote">On Mon, 27 Apr 2015 at 20:03 Sylvestre Ledru <<a href="mailto:sylvestre@debian.org">sylvestre@debian.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <div>Le 27/04/2015 10:43, Angus Lees a
      écrit :<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">On Mon, 27 Apr 2015 at 17:17 Sylvestre
          Ledru <<a href="mailto:sylvestre@debian.org" target="_blank">sylvestre@debian.org</a>>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">
              <div>I like the idea and I think it makes sense.<br>
                I am just afraid about the libstd-$hash having to
                through new every time...<br>
              </div>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>This shouldn't be any different to regular lib$soname
            bumps for C-based packages.</div>
        </div>
      </div>
    </blockquote></div><div bgcolor="#FFFFFF" text="#000000">
    Except that they will change at every release for a while, don't you
    think?</div></blockquote><div><br></div><div>Yes, it looks like the plan is to change the hash every release, which means every 6 weeks.</div><div><br></div><div>I don't know what the threshold is for "too often", so we might need to just try this for a bit and see(?).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>  I haven't maintained a C library package before, but
            afaik you only go through the NEW process for new source
            packages, not renamed binary packages.</div>
        </div>
      </div>
    </blockquote></div><div bgcolor="#FFFFFF" text="#000000">
    No, ditto for renamed binaries.</div></blockquote><div><br></div><div>Huh, I learnt something new :)</div><div>Yes, the above means we'll need to go through the "binary-only" version of the NEW process for each new upstream release.  Again, I don't know how much of a delay there will be in that.</div><div><br></div><div> ----------</div><div><br></div><div>I've pushed an update that implements the proposal to a new alioth/multiarch branch.  Let me know if you see any blockers to merging it onto master.  The only lintian warnings currently are that rust-{gdb,lldb} don't have manpages, and that "epub" isn't a recognised doc-base format (I'm still unsure whether I want to file the feature request or just remove the epub doc-base entries).</div><div><br></div><div><br></div><div>Re the libstd-rust-$hash package name:   I attempted to name it just "libstd-rust" but this requires an additional "<< $next_upstream" dependency restriction in shlibs.  We can add that, but doing so seemed to be strongly advised against in the library packaging guide that I was browsing through at the time - and they pointed to previous examples where not just using the soname as was intended led to various corner-case issues.</div><div><br></div><div>I've implemented the libstd-rust-$hash package as would be expected without concern for release frequency because I would like to gain experience with the "right" thing and have actual data before making compromises.  If it turns out we _are_ releasing "too frequently",  I think our next best alternative is to abandon the libstd-rust-$hash split out for now and just roll the runtime libs into libstd-rust-dev, rather than making a non-soname "libstd-rust" package.  This alternative means we won't be able to depend on dylibs from other Debian packages, which is the use case we expect to not handle at present anyway.  One day it is inevitable that we _will_ have a package that needs the dylibs and then we won't have a choice, but this alternative would let us postpone any maintenance costs until that day.</div><div><br></div><div> - Gus</div></div></div>