Hi,

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.

End users(aka normal Go developers) don't need these -dev packages.

Copying what we stat on https://go-team.pages.debian.net/packaging.html

These packages in the main package are not problem currently, but someone thinks:

These packages index/info will be downloaded to users' compute, it wastes disk, and
apt will be less efficient, etc...

So I suggest we can have somethings like dbgsym package repo.

A keyword in Control-Filed to reflect these packages, then move them to another repo.

[1] I'm more familiar with Go than rust though.

Thanks

Shengjing Zhu

-----BEGIN PGP SIGNATURE-----

iIYEARYIAC4WIQTiXc95jUQrjt9HgU3EhUo4GOCwFgUCXiHhPRAcemhzakBkZWJp
YW4ub3JnAAoJEMSFSjgY4LAWFSIA/0pbE5z7OY1opij/WT4uSY9NbS0+luuOs19D
ruD/eLNUAQCv3dcRDtMT/w2nmsukRNWb1oJDI79mXH+K4MdRRC2wBA==
=exaC
-----END PGP SIGNATURE-----

I think you mean to say that "-dev" packages are designed for developers
only.

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".

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.

I think you're making the scope broader.

What in my mind is the golang-*-dev packages(I take librust-*-dev into
account since I think they are similar, but anyway I'm not familiar
enough).
These are explicit documented that user shouldn't install them.
Except you(aka _debian_ developer) are building a deb package for
_Debian_, but it's usually in a chroot(more specifically, a buildd
variant chroot).
It's even not recommended to use these packages to build deb not for Debian.

On Sat, Jan 18, 2020 at 2:57 AM Daniel Kahn Gillmor <dkg@debian.org> wrote:
·[...]

Take a specific example,

I(as a Go developer) write a Go program, which imports
github.com/containerd/btrfs[1].

I'm expected to install libbtrfs-dev from OS archive, but not
golang-github-containerd-btrfs-dev.

[1] which needs a C library as build time dependency .

I think a Go developer would use the "main" archive section, not the
proposed "nodev" archive section.  That seems like it will work fine.

If they're resource-constrained to the point where a few thousand
entries in the apt database makes a difference, they're not developing
Go on that machine, so they have no need of the reduced resource
consumption of the "nodev" archive section.

I think that these packages are solely a workaround for apt/dpkg not
supporting the ability to build-depend on and use (parts of) another
source package. I think that therefore we should enhance apt/dpkg and
remove all the golang/rust binary packages instead.

This doesn't work for Rust unfortunately, due to features. Based on which feature-set is activated, when you depend on a source-package you would want to pull in different sets of transitive dependencies.

However, a combination of:

1. implicitly being able to install source packages into /usr/src
2. metadata-only binary Packages that can depend on these implicit source packages

would work.

X

This applies to Go too. Currently a source-package's build-depends
usually include those for testing purposes, which are not needed when
building the rdepends. Or we don't test it, or we have a separate
control-filed in source-package..

These metadata-only binary packages would still consume the shared
resources that people have been complaining about.

So I think this approach would still need some sort of specialized
section of the archive to avoid bloating the package lists for people
who aren't interested in being developers.

IIRC the proposals about build-depending on source packages included
being able to build-depend on their build-depends. If you could also
filter those build-depends by build profiles then that might work.

Paul Wise:

Filtering by build-profile doesn't work as we have no mechanism to say that build profile A should automatically imply build profile B on a dependency.

X

aiui, pabs means that build-dependencies that are only for running
package tests will be marked explicitly with !nocheck, so that we don't
end up with dependencies on test suites of dependencies.

i don't think pabs was contemplating rust-style feature chains.