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, josch
signature.asc
Description: signature