Global caveat, I don't pretend to represent all of Fedora. I'm just answering to my best understanding, and it's a bit theoretical since real Fedora packages don't exist yet. This also went very long, so I hope I didn't cross my wires anywhere...
I don't think it's so important to align upstream and downstream packaging. Certainly each distro will have different policies about the nitty gritty subpackaging.
But as a general guideline, I do agree it's a good idea to suggest a meta package to pull in the basics. Sort of like the haskell-platform
package, which is nearly empty but depends on all the other packages to complete the platform.
Currently Fedora uses /usr/share/doc/$NAME
, but it used to have $NAME-$VERSION-$RELEASE
. The best practice is to use the %doc
macro right in the build directory, without otherwise installing them at all. There's a similar %license
macro too. An html
subfolder for docs is fine too.
I'm not sure if Fedora really deals in such things. There's the "alternatives" system, but I think that's usually for completely different implementations, like java runtimes or the mta. My guess is if multirust were to be packaged at all, it would only be useful to manage user-installed rust versions, not the distro package.
Ideally, if stability and eventually ABI is done right, this won't be necessary. Fedora's only alternate gcc is compat-gcc-34
, so we're reaching way back here. Those executables are installed with simple suffixes, gcc34
, g++34
, et al, and the rest of gcc's runtime is already taken care of, isolated like /usr/lib/gcc/$target/$version/
.
I would like Cargo to have its own proper release and source tarball, yes. Especially since the versions don't match, I think it should be built as its own srpm distinct from rust itself. I don't really care if it's released in lockstep, but I suspect it will be anyway since they're practically developed together. Just need to know which rust-x.y is required for that cargo release, even if that's always the latest.
Bootstrapping from the previous release would be fantastic. Then stage0 will only be needed once, and we can self-build from then on. That exactly matches Fedora's exceptions to the ban on prebuilt binaries.
I guess for rebuilding the current version, say for a minor bug or security fix, there's a way to skip the initial stage? I haven't tried in a while. Point is just that this is a case where the existing rustc is already the same version as what we're building, so it might need to skip over some assumptions about what the "snapshot" contains.
As for the 6-week release train, I fully expect Fedora Rawhide to keep up with this. If the package maintainers slack off, then it will be justified penance to make them step through 6-week increments, no problem. I don't see the value of an upstream build script doing this, because then you'd need all those intermediate sources in the srpm.
Then in released Fedora, either we'll have answered the questions like ABI sufficiently that they should keep up every 6 weeks too, or else they'll be locked into some specific version and never need to worry about bootstrapping again. The next Fedora release will just have inherited from Rawhide which will be keeping up.
A blessed Cargo bootstrapping script would also be great. If not, then it'd be nice to follow the same suggested model as Rust, building with the prior Cargo release, with consideration for rebuilding on the current release too.
I personally don't like rpm-generators and the like, if that's what you mean. It just needs to have the right knobs to control installation paths, bindir, libdir, etc., since distros have different ideas about this. A DESTDIR
control on the install command is also needed, e.g. even though I have prefix=/usr
, I'll want to install to $DESTDIR/usr/...
during the package build.
Are you talking about source packages, or just the binary packages you distribute? I suspect the latter. The source of the standard library seems inseparable from the rest of the compiler, and should be part of the distribution - much like how libstdc++ is always part of gcc. (at least these days; not sure if that's historically always been true.)
For just binaries, meh. I think distros will vary, and upstream doesn't need to try to align how packages are named. It's good enough to just specify how rustlib/$triple
should be found. For Fedora, I expect we'll just build everything natively, with those libs in their own subpackage, and then an x86_64 host can just install that rustc-libs.i686
compat package like all other compat libraries are handled.
Well, if it's so close already, why not take the goal of switching to stock LLVM altogether? Those few unwanted optimizations -- can you provide references to these discussions? Maybe they might be accepted with some rework? (but I don't know what these are...)
Anyway, yes, Fedora is one that would prefer not to use bundled LLVM. It's possible to get exceptions, but better if we don't need to. And this really ought to be dynamically linked too.
We usually deal with distro CFLAGS
or equivalent in an rpm macro like %optflags
. For example, Fedora's 32-bit x86 target currently gets
"optflags: %{__global_cflags} -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables
". I imagine we'll add something similar for rust packages, and in their spec then can just run something like cargo build %{rustflags}
, or maybe even just %{cargo_build}
.
Right now Fedora's %__global_ldflags
just has hardening options.
I haven't looked at those before, but at a glance, no I don't think Fedora needs that. That is, we need to run something like cargo install
or whatever at rpmbuild time, but in the user's hands install/uninstall task should be fully handled by rpm itself. Maybe it could be useful to produce a manifest to aid the rpm %files
section. But since things are usually installed in a clean DESTDIR
, you can usually just wildcard entire paths.
As for consistency across distributions -- what are you hoping for specifically? What problems are you trying to avoid? Distros all have their own policies, so I don't think you'll get a complete homogeneity here...
Package names, division, cross-std, are all going to vary on distro policy. For bootstrapping, I think we just need clear instructions how to do it, especially offline, whether from stage0, the prior release, or rebuilding the current release. Certainly branding and trademark guidelines need to be stated if you expect any control there.
I'm not sure. There's enough interest that a few people have uploaded binary packages on copr, and I'm sure those users would prefer an upstream repo. Even after it is in Fedora proper, your own repo still might be useful if Fedora ends up staying conservative on updates. Beta and nightly repos might be cool too. BUT - if you're messing with all that, you probably want multirust with user-installed rustc, so rpm repos are beside the point.