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

[Angus Lees]

Oh, and I dropped libstd-rust-multiarch-dev.  It turns out you need a C
compilers available for any target (for lib{compiler-rt,morestack}.a), and
when I went looking, Debian didn't seem to have compilers available for any
of the non-Debian architectures (ios, android, etc).  The exception was
Windows/mingw, so I thought we might package up a libstd-rust-mingw-dev at
some point but I haven't done so here.

>From reading code and some quick experiments, I also discovered that rustc
+ system LLVM seem capable of compiling to all supported platforms out of
the box - you just need to have the relevant target libs available (and
building additional libs is the only thing the ./configure --target option
ends up doing).  So there is zero increase in rustc.deb size over what we
were already building before.  If you didn't already know about it, rustc
also the ability to define new platform triples (that use already supported
cpu architectures) by dropping JSON definition files into a particular
directory - but I haven't tried this myself yet.

 - Gus

On Wed, 6 May 2015 at 15:10 Angus Lees <gus at debian.org> wrote:

> 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/2bc46ced/attachment.html>