| Message ID | cover.1608149415.git.h.goebel@crazy-compilers.com |
|---|---|
| Headers | show |
| Series | Update sequoia-opengpg to 1.0.0 | expand |
Hello,
Hartmut Goebel <h.goebel@crazy-compilers.com> writes:
> v1.0.0 was released just today. Here is the update :-)
Thank you.
I think the big warning in rust-dbl-0.3's description could be removed.
Also, I notice you often skip builds, even though this is not required.
E.g., I could build rust-pin-utils-0.1 without any problem just removing
the #:skip-build keyword. I think the trend is use #:skip-build only
when absolutely necessary.
Finally, I wonder if replacements, e.g., rust-capnp-futures-0.10 by
rust-capnp-futures-0.13, require to remove the old variable. It could be
used out of the code base.
WDYT?
Regards,
Hi Nicolas, > > I think the big warning in rust-dbl-0.3's description could be removed. Fine for me. will do. > Also, I notice you often skip builds, even though this is not required. > E.g., I could build rust-pin-utils-0.1 without any problem just removing > the #:skip-build keyword. I think the trend is use #:skip-build only > when absolutely necessary. Building crate "libraries" is of no use. Rust still has no notion of "libraries", neither shared not static. it does not even provide any means to use "object"-files from another package. All crates will be build again and again for each package using it. And you will notice that the output of most crates will be almost empty (only exception: if the crate build a program). This is why the crates importer sets skip-build for all packages it imports as dependencies. (It also does not add the crate-build-dependencies for these packages.) > Finally, I wonder if replacements, e.g., rust-capnp-futures-0.10 by > rust-capnp-futures-0.13, require to remove the old variable. It could be > used out of the code base. We are lacking a common practice on this yet. IMO it does not make much sense to provide packages for old crates. crates are using semantic versioning, so in the long run we might end up maintaining hundreds of old packages. Concrete for this bunch of packages: These have been added by myself when packaging sequoia last April. So maybe thos turns the balance :-)
On Thu, Dec 17, 2020 at 05:05:58PM +0100, Hartmut Goebel wrote: > Hi Nicolas, > > > > I think the big warning in rust-dbl-0.3's description could be removed. > > Fine for me. will do. > > > > Also, I notice you often skip builds, even though this is not required. > > E.g., I could build rust-pin-utils-0.1 without any problem just removing > > the #:skip-build keyword. I think the trend is use #:skip-build only > > when absolutely necessary. > > Building crate "libraries" is of no use. Rust still has no notion of > "libraries", neither shared not static. it does not even provide any means > to use "object"-files from another package. All crates will be build again > and again for each package using it. And you will notice that the output of > most crates will be almost empty (only exception: if the crate build a > program). > > This is why the crates importer sets skip-build for all packages it imports > as dependencies. (It also does not add the crate-build-dependencies for > these packages.) I'm in favor of building the packages anyway, it serves as a check that the inputs are actually correct. > > Finally, I wonder if replacements, e.g., rust-capnp-futures-0.10 by > > rust-capnp-futures-0.13, require to remove the old variable. It could be > > used out of the code base. > > We are lacking a common practice on this yet. IMO it does not make much > sense to provide packages for old crates. crates are using semantic > versioning, so in the long run we might end up maintaining hundreds of old > packages. > > Concrete for this bunch of packages: These have been added by myself when > packaging sequoia last April. So maybe thos turns the balance :-) > As long as you're sure there's nothing else in tree that's depending on it, I suppose it's ok to remove them. I view it similarly when I clean up package names to drop not significant digits from the versioning in the name, ie rust-slog-2.5 -> rust-slog-2. If the rust ecosystem slows down some I'd be happy to keep more versions but it's already one of the largest package modules we have.
The discussion about how to package crates did not got an actual momentum. Also this will become a topic on Guix day, which is in 4 weeks time. I don't want to have this path hanging around that long. Thus I propose: For this patch: - For updated packages and packages where a new semver-version was added, #:skip-build will be kept. - For newly added packages the value set by the crate importer will be used (which is #:skip-build #t) WDYT? If you agree, I'm going to update the patches and commit.
On Wed, Jan 06, 2021 at 07:05:28PM +0100, Hartmut Goebel wrote: > The discussion about how to package crates did not got an actual > momentum. Also this will become a topic on Guix day, which is in 4 weeks > time. > > I don't want to have this path hanging around that long. Thus I propose: > > For this patch: > > - For updated packages and packages where a new semver-version was > added, #:skip-build will be kept. > > - For newly added packages the value set by the crate importer will be > used (which is #:skip-build #t) > > WDYT? If you agree, I'm going to update the patches and commit. Your plan sounds good to me.
Pushed as a240686cc34454a3221c31f3c546985c2c90bf2c