On Wed, Nov 11, 2020 at 02:26:55PM +0100, Matthias Klose wrote: > On 11/10/20 10:51 PM, Joerg Jaspert wrote: > > On 15948 March 1977, Paul Wise wrote: > > > >> Does this include the -dev packages for C/etc libraries? > > > > No. > > > >> I guess it also applies to Haskell and other statically-linked languages. > >> https://wiki.debian.org/StaticLinking > > > > StaticLinking itself is not enough. This is about languages where the actual > > development in it is discouraged from doing with the debian packaged stuff. > > Where you do not go "I need lib XY, i install libxy-perl/libxy-dev/whatever the > > name" and hack around using it. But "Oh, i want to hack on foo, i go get > > foo/cargo .../whateverthetool" and the debian package only ever comes in play if > > you do build debian packages using it. > > If you ask some upstreams of Python based software, their recommendation would > be to use pip, and probably conda (a cross OS distribution focusing on Python) > to do upstream development. If you ask casual users, you probably will get > another answer. > > Same thing probably for Java libraries. I don't know anybody who would do > development using the Debian packaged libraries. > > > > >>> 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? > > > > No, if so we would have split that section out. > > Reducing the size of the index file is a technical issue inside Debian, and > relating that to > > """ > languages where the actual development in it is discouraged > from doing with the debian packaged stuff > """ > > seems to be wrong, as any upstream eco system providing their own environment > for development and distribution would need to move to this section. I don't > think the reference to upstreams doesn't help with the definition of the new > section. The thing we should aim for, the thing I'm aiming for, is that software developed in any programming language can be distributed by Debian. User point of view: `apt install foo` Debian policy p.o.v. `apt-get source foo` > Matthias > Regards Geert Stappers -- Silence is hard to parse
Attachment:
signature.asc
Description: PGP signature