[Pkg-rust-maintainers] Rust multiarch-friendly package/filesystem layout proposal

[Angus Lees]

On Mon, 27 Apr 2015 at 20:03 Sylvestre Ledru <sylvestre at debian.org> wrote:

> Le 27/04/2015 10:43, Angus Lees a écrit :
>
>  On Mon, 27 Apr 2015 at 17:17 Sylvestre Ledru <sylvestre at debian.org>
> wrote:
>
>>  I like the idea and I think it makes sense.
>> I am just afraid about the libstd-$hash having to through new every
>> time...
>>
>
>  This shouldn't be any different to regular lib$soname bumps for C-based
> packages.
>
> Except that they will change at every release for a while, don't you think?
>

Yes, it looks like the plan is to change the hash every release, which
means every 6 weeks.

I don't know what the threshold is for "too often", so we might need to
just try this for a bit and see(?).

    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.
>
> No, ditto for renamed binaries.
>

Huh, I learnt something new :)
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.

 ----------

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


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.

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.

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150506/61721b66/attachment.html>