Perfecting Rust Packaging

[brson]

@Keruspe

I didn't read the whole thing yet (I plan on doing it later today), but as the rustc packager for Exherbo, the main critical blocker for us atm is Problems with linking with system-wide installed libraries · Issue #16402 · rust-lang/rust · GitHub (which doesn't seem to have been mentioned here yet)

Thanks for the link. I've noted it.

@gus

Currently we also repack the source tarballs to remove src/llvm/* (unneeded, and big) and src/etc/snapshot.pyc (shouldn't be in the upstream tarball anyway).

Thanks. Filed an issue.

@gus

Note that even when we kept the full src/llvm/ source, we still had to remove src/llvm/cmake/modules/LLVMParseArguments.cmake because CC-BY 2.5 isn't DFSG-free

Thanks for bringing this to my attention. Here's another issue.

@gus

I think this means we'll need to improve the Debian build to detect version and jump straight into stage2 for the former case, since stage1 won't build with its own release (until upstream moves away from using #[cfg(stage0)] as a versioning mechanism) - this doesn't sound too bad, but I haven't actually done it yet so I don't know what traps await..

I've made a note of this self-re-bootstrapping requirement. We can bake this functionality into the makefiles, including bypassing the feature checks so you don't need to package nightly.

@gus

In a hypothetical future Debian stable release ...

Thanks for all this explanation and the link to your proposal.

@mzabaluev

No, I meant that the binary package naming/dependency metadata should be so that you can install librust-std for the host platform using just its short name without the target triple (using Fedora as an example):

Thanks for the clarification.

@cuviper

Once we get bootstrapped, the Fedora build root will have whatever rustc package is currently stable. So if we're on rustc-1.4.0-1, and we want to build rustc-1.5.0-1, that's fine, it's the previous release. Then a point release appears, we need to build rustc-1.5.1-1 using the buildroot's 1.5.0 we made earlier. Then if we need to rebuild for any reason, now rustc-1.5.1-2 will be built from 1.5.1-1.

There are ways to override the buildroot, but I don't think you can tag obsolete packages that way. Usually overrides are used to bring in some new package to chain build others, before sending them all to stable.

It sounds like @gus is also describing the same thing about jumping to stage2, but I hadn't even considered the problem of feature use. I don't think multiple --release-channel builds should be necessary -- there ought to be an option for even stable builds to use features. There's no need to be draconian, just let advanced use cases be advanced. IMHO

Thanks for the description, and agree that rebootstrapping shouldn't require nightly. We'll solve that in the makefiles.

Edit: Heh, I just realized how terse this message was. 'Thanks!'. It's late here.