On Sat 2020-01-18 00:31:11 +0800, Shengjing Zhu wrote: > There're a lot of packages in archive which users are not expected to > install, for examples: > > * all golang-*-dev packages. (currently there are 1k+) > * maybe[1] all librust-*-dev packages. (currently there also are 1k+) > > For Go, these packages are only meant to build other Go program (usually > arch:any), and in the scope of producing Debian packages.
I think you mean to say that "-dev" packages are designed for developers
only.
> End users(aka normal Go developers) don't need these -dev packages.
Arguably, if i'm going to work on go software in the debian context, i
might indeed want these packages. But the distinction isn't "end users
vs. debian developers", it's more "end users vs. developers". Normal Go
developers might well fall in the second camp because they need other
development tools that the OS can give them.
So I think the more useful cut is between packages that are for
development purposes (-dev packages more generally) and packages that
are intended for non-developers.
For example, a minimalist system running debian, that will never see any
software development, and wants automatic updates, could conceivably
just want to use a generic "non-developer" repository.
One approach would be to split the "main" archive section into a
"non-developer" base section, and a "developer" augmented section
(similar to the relationship between "non-free" and "contrib" sections).
Another approach would be to leave the current "main" section as-is, but
create a "nodev" section which is a strict subset of "main". This
latter approach seems like less of a dramatic shift in the current
archive.
If there were a "nodev" section, i'd definitely deploy any minimal
IoT-style debian devices pointing at "nodev".
> A keyword in Control-Filed to reflect these packages, then move them to
> another repo.
You could start experimenting with this by stripping the archive of all
*-dev packages and anything that depends on them, and see whether it
results in a manintainable, standalone repo.
Would you be up for doing that and publishing the repo someplace for
people to play with it? That would give us a sense of how feasible this
approach would be.
--dkg
signature.asc
Description: PGP signature
