Quoting Andrej Shadura (2020-11-10 10:27:44)
> On Tue, 10 Nov 2020, at 08:28, Paul Wise wrote:
> > > The current proposal is to reduce the main Packages.xz files size by
> > > splitting[4] out all of the packages that are not intended for users,
> > > writing those into an own file. Those packages would have a section of
> > > "buildlibs", independent of their other properties.
>
> > Should (almost?) everything in the existing libdevel section move to
> > the new buildlibs section?
>
> I wouldn’t say so.
>
> If I install, say, libftdi-dev, I expect to be able to do actual development
> with it, for Debian or not. In fact, installing libftdi-dev would be the
> first thing I do if I were to develop with the library.
>
> On the contrary, if I’m going to do some development with, say, clap (Rust
> command-line arguments parser), I wouldn’t install librust-clap-dev; more
> than that, if I actually did, I’d be very difficult for me to actually use it
> to develop an app.
Aha. Would it?
I have the following in my ~/.cargo/config.toml:
[source.deb]
directory = "/usr/share/cargo/registry"
[source.crates-io]
replace-with = "deb"
[net]
offline = true
Then I clone some upstream git repo that uses clap:
git clone https://github.com/dotenv-rs/dotenv.git
And then I run "cargo build". Every time I get a message like:
error: no matching package named `foo` found
I install librust-foo-dev until finally:
Parent pid 535147, child pid 535148
Child process initialized in 30.93 ms
Compiling proc-macro2 v1.0.18
Compiling unicode-xid v0.2.0
Compiling syn v1.0.12
Compiling dotenv v0.15.0 (/tmp/dotenv/dotenv)
Compiling quote v1.0.7
Compiling proc-macro-hack v0.5.9
Compiling dotenv_codegen_implementation v0.15.0 (/tmp/dotenv/dotenv_codegen_implementation)
Compiling dotenv_codegen v0.15.0 (/tmp/dotenv/dotenv_codegen)
Finished dev [unoptimized + debuginfo] target(s) in 9.93s
Parent is shutting down, bye...
So how is this "very difficult"? The steps are the same as when I clone a
Python upstream git repo and I get the message "ModuleNotFoundError: No module
named 'foo'" -- I just install python3-foo and it will work. Same here with
rust and the librust-foo-dev packages.
I do not deny that many upstreams will tell developers to use cargo, pip, go
get... whatever to manage their software. Personally, I rather avoid using
these package managers and use the packages provided by Debian instead. There
are real advantages over using the packages from Debian. Instead of relying on
another 3rd party repository where anybody can upload anything, I benefit from
the additional work put in by DDs to make sure that no garbage ends up in the
archive. Rather than the "fast-paced" development style that seems to be modern
these days, I prefer the stability and security that I get by sourcing all my
code and libraries from the Debian archive. With Debian packages, I cannot
really get typosquatted, I know that all software is DFSG-free and I know that
I will receive security updates.
This is not an argument against splitting "main" into several archives. I'm no
big fan of this solution but maybe it should be done. What I want to make an
argument for in this email though is, that I do not believe that our packages
have no value outside compiling other Debian packages even for languages where
upstream prefers its users to use their own package manager. There are many
reasons to prefer the trusted Debian sources for quality, security and software
freedom and if any split is done, it should not be made in a way that makes it
harder for our users to install those packages. They have real value.
At this point let me also give a big thank you to all the nodejs, python, rust
etc package maintainers for taking on the tedious task of making Debian
packages for software that is already present in another repo. It's really
great stuff -- thanks a lot!
cheers, joschAttachment:
signature.asc
Description: signature