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.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted