Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Produce packaging guidelines #29563

Open
brson opened this issue Nov 4, 2015 · 7 comments
Open

Produce packaging guidelines #29563

brson opened this issue Nov 4, 2015 · 7 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. P-low Low priority T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@brson
Copy link
Contributor

brson commented Nov 4, 2015

Summarize what we've learned into some general guidelines for packagers.

Potential topics:

  • Maintaining independently-bootstrapped Rust compilers.
  • Packaging Cargo libraries / applications
  • Generating offline docs

re https://internals.rust-lang.org/t/perfecting-rust-packaging-the-plan/2767

@brson brson added the A-docs label Nov 4, 2015
@steveklabnik
Copy link
Member

At what point are we far enough along that I should start work on this?

@steveklabnik
Copy link
Member

@brson ping! Have we gotten far enough for me to write these docs yet, and how would I go about finding that information?

@brson
Copy link
Contributor Author

brson commented Aug 2, 2016

We could probably produce some guidelines now. But it would take some investigation to figure out both what packaging-related features we're providing and what packagers are actually doing in practice, and to make sense of it. It's all pretty fuzzy to me still.

I could probably spend a day collecting notes together, then bounce them off our packagers to see if they make sense. Low priority still.

@oconnor663
Copy link
Contributor

Lots of packaging discussion at https://internals.rust-lang.org/t/beta-testing-rustup-rs/3316/188

More Arch Linux specific discussion at https://aur.archlinux.org/packages/rustup/?comments=all

@cuviper
Copy link
Member

cuviper commented Feb 3, 2017

I was just asking @brson for a judgement whether it would be kosher for distros to patch 1.15.0 with #39466, changing a public interface. He indicated discomfort. This particular point is moot if there's going to be a 1.15.1 point release, but there's a larger question here.

What would the Rust Project find acceptable for downstream builders to change? I'd expect general bug fixing to be allowable, but changing a public interface gets questionable, I agree. Do we need to say anything more than that?

Interface questions could also come up if there's ever a separate compiler implemented, say gcc-rust.

Of course, the license permits pretty much any change you like, but maybe there's some trademark muscle to flex behind this policy, if needed. Or maybe you just grumble about out-of-spec implementations.

@steveklabnik steveklabnik added the A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools label Mar 10, 2017
@steveklabnik steveklabnik added the T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. label May 24, 2017
@steveklabnik
Copy link
Member

Triage: tagging as T-infra as well; docs team is happy to help here, but we'd need you all to get a rough draft together.

@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 24, 2017
@steveklabnik steveklabnik added the P-low Low priority label Aug 30, 2017
@steveklabnik
Copy link
Member

tagging as p-low, @rust-lang/infra , let the docs team know when you want to collaborate on this

@steveklabnik steveklabnik removed the A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools label Jan 8, 2019
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. P-low Low priority T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants