rust-lang-deprecated / rust-packaging Goto Github PK

While Debian has an effort to package Rust, I think it is slow going. ISTM we could with relative ease produce debian packages that work most everywhere as part of our build process.

The previous installer which only installed rust would ask for you to enter a admin password. The new installer which installs both rust and cargo fail instead requiring you to run it as an admin.

This file is LGPL licensed but we don't mention that anywhere.

Building packages requires having the source tarball, which not all platforms even build. This should be pretty easy to remove with the right metadata.

It would be nice to formalize our package upgrade policy. In other words: When packages may be installed side-by-side, and when they are mutually exclusive?

A straw-man policy proposal, which seems to yield intuitively correct results: "The (target, channel, major, minor) tuple must be unique per-machine". Some examples of what this would mean:

• Any 32-bit installation will co-exist with any 64-bit one (target is different).
• Installing a nightly replaces previous day's nightly (they only differ in build revision).
• Nightly, beta and stable with the same major.minor version will co-exist.
• Installing 1.0-alpha.2 will uninstall 1.0-alpha.1. Installing 1.0-beta.1 uninstalls any 1.0-alpha. And so on...
• 1.0.x-stable will co-exist with 1.1.x-stable, but 1.0.1-stable will replace 1.0.0-stable.

Right now I'm looking at a red CD icon, but it'd be cool if we could get the Rust gear in there!

cc @vadimcn

cc rust-lang/rust#32283

@brson: The whole "Check here to accept License Agreement" business seems pretty lame for an OSS project. I am guessing this came about only because that's what the default installer UI package offers?
How about we replace license with something useful, such as release notes?

Wishlist item. The conversion between packaging formats could be done in rust-installer, aside from configuration.

For the Visual Rust Toolchain Manager, I'm playing around with the MSI and getting unattended per-user installs to work.

If you want to play along, try something like: msiexec /i some-rust-installer.msi /quiet /l* log.txt INSTALLDIR=C:\Users\Me\Desktop\RustTmp

I haven't figured out how to avoid it requesting admin privileges. Maybe http://blogs.msdn.com/b/windows_installer_team/archive/2009/09/02/authoring-a-single-package-for-per-user-or-per-machine-installation-context-in-windows-7.aspx helps?

To make proper packages, you HAVE to use pkgbuild on a Mac, or possibly BOMUtils on Unix-like OSes.

Then you have to use tar+xz to create the Payload file which contains the actual executables, and a separate tar+xz Scripts file.

So long yak hair short, I wanted to be able to see if a particular commit to cargo was shipped with a particular released version of rustc. Unless I'm missing something, this information isn't straightforward to find anywhere!

I got really excited when I saw the cargo-revs.txt file in this repo, though, finally! Here it is! The git rev SHAs that were shipped with rustc! Oh wait-- it's only the date of the nightly that was used :( :( :( Which isn't always the last commit on that date...

So then I found the nightly cargo trigger of buildbot's, went to the build for a particular date (say, 2016-08-21) and that page says "got revision 109cb7c33d426044d141457049bd0fffaca1327c" which matches what I see if I do rustup default beta (since beta is 1.12.0 right now) and say cargo --version: cargo 0.13.0-nightly (109cb7c 2016-08-19).

I did that with other versions until buildbot ran out of builds to give me (it looks like it only keeps the last 500), so I think I have the correct SHAs.

Even though rust-packaging doesn't need these revs, would it be terrible to include them in cargo-revs.txt for future human reference and parse them out and have the code ignore them?

I'm also about to open an issue with cargo about tagging these commits with something to indicate the rustc version they went with, so if that seems like a better solution then feel free to close this :)

Here's the SHAs that I found and the buildbot source links, let me know if you'd like a PR in any particular format if you're in favor of this!

1.0.0: 2015-04-30 ?????
1.1.0: 2015-05-16 a48358155c90467ed9c897930dd0da4614605dac https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/144
1.2.0: 2015-07-10 15b497b10c8261f09f15130595f696fcf29c3619 https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/203
1.3.0: 2015-08-03 553b363bcfcf444c5bd4713e30382a6ffa2a52dd https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/228
1.4.0: 2015-09-14 833b947016f4fb5269ef4bc5448e4d79eb3b475b https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/271
1.5.0: 2015-10-27 e1ed9956e079a563796fb380871f4b67619f58ee https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/314
1.6.0: 2015-12-09 1af03beaffe9be40ae81ca39431c1f1651ef6b02 https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/357
1.7.0: 2016-01-18 9ebfb9b6d2bad7f9640ae012fae686ceeab7b084 https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/397
1.8.0: 2016-03-01 8fc3fd8df3857f3e77454c992458cd7baeeb622b https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/442
1.9.0: 2016-04-10 10ddd7d5b3080fb0fa6c720cedca64407d4ca2f9 https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/484
1.10.0: 2016-05-22 259324cd8f9bb6e1068a3a2b77685e90fda3e3b6 https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/526
1.11.0: 2016-07-05 6b98d1f8abf5b33c1ca2771d3f5f3bafc3407b93 https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/567
1.12.0: 2016-08-21 109cb7c33d426044d141457049bd0fffaca1327c https://buildbot.rust-lang.org/builders/nightly-dist-cargo-trigger/builds/614

The mingw build of rust ships with libstdc++-6.dll and libgcc_s_seh-1.dll in the bin path. This can conflict with a system (mingw/msys) installed version of those DLLs, and can cause weird errors -- for example, trying to build rust-bindgen against the system libclang.dll results in a bindgen.exe that doesn't start, because it tries to use rustc's libstdc++-6.dll, whereas libclang.dll needs a newer/different libstdc++.

A solution for this is to use manifest files and move these two DLLs to a private directory that's not in the path. In the rustc bin dir:

rustc.exe.manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    version="1.0.0.0"
    processorArchitecture="amd64"
    name="APPLICATION"
    type="win32"
/>
<description>Rust Compiler</description>
<dependency>
    <dependentAssembly>
       <assemblyIdentity
           type="win32"
           name="Rust.PrivateRuntime"
           version="1.0.0.0"
           processorArchitecture="amd64"/>
    </dependentAssembly>
</dependency>
</assembly>

Rust.PrivateRuntime.manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity type="win32"
      name="Rust.PrivateRuntime"
version="1.0.0.0"
processorArchitecture="amd64"/>
    <file name="rust-private\libstdc++-6.dll"/>
    <file name="rust-private\libgcc_s_seh-1.dll"/>
</assembly>

And then moving libstdc++-6.dll and libgcc_s_seh-1.dll to a new rustc/bin/rust-private/ directory.

(Note to manually test this out, you have to touch rustc.exe after creating rustc.exe.manifest, otherwise the manifest won't be read.)