4 ms·

What I would like to see is: 1) a unified database for package names (it's all unnecessarily ad-hoc right now, with different distros having different policies

by dTal 4y ago

What I would like to see is: 1) a unified database for package names (it's all unnecessarily ad-hoc right now, with different distros having different policies for capital letters, whether libraries are prefixed with "lib", whether python packages have "py" or "python" or "py3" etc... 2) a standard format for declaratively describing how to build a package. Basically, we have FreeBSD ports, Arch PKGBUILDs, Void templates, Gentoo ebuilds - they all do more or less the same thing in the same way, they all work really well, and they're all incompatible for sheerly incidental reasons. I'd like to see these incompatibilities papered over in such a way that I can write one template and generate all the others.

rand_flip_bit 4y ago
Congrats you just invented containers :P
- dTal 4y ago
  Not sure how you figure that. Containers are completely orthogonal to both of my requirements, which again are 1) a globally canonical package namespace, and 2) tooling to convert some standard recipe file format into distro-specific recipe files (which would require point 1 to work).
account42 4y ago
There are already many standard build specification formats: CMake, autotools, Meson. For each, most distro's package managers can build the software with very little configuration, e.g. Debian's debhelper will cover most standard build systems and Gentoo has eclasses that you just need to inherit in a package. I'm not sure that adding another makes things easier. Configuration options will need to be specified manually if you want any but I don't see a way around that as they are both package-specific and also something where distros want to differ. For dependencies there are usually language-specific registries and pkg-config for C/C++-land. Some distros (e.g. RPM-based-ones) already support specifying dependencies by the pkg-config names or library SONAMEs. There is no distro-agnostic way to specfy your dependencies except for a README as far as I know - this would be something worth specifying.
t43562 4y ago
You'll invent new standard and have N+1 standards. It's not as if package formats can't be declarative - just that some issue always turns up in package X or Y that the declarative format didn't anticipate. I think there may indeed be tools to convert these formats but in the end the devils are always in some distro-specific set of details that make life miserable. e.g. your library has some option enabled or doesn't and some other package in that distro needs it and so on and on.

by dTal 4y ago

rand_flip_bit 4y ago

Congrats you just invented containers :P

dTal 4y ago
Not sure how you figure that. Containers are completely orthogonal to both of my requirements, which again are 1) a globally canonical package namespace, and 2) tooling to convert some standard recipe file format into distro-specific recipe files (which would require point 1 to work).

account42 4y ago

There are already many standard build specification formats: CMake, autotools, Meson. For each, most distro's package managers can build the software with very little configuration, e.g. Debian's debhelper will cover most standard build systems and Gentoo has eclasses that you just need to inherit in a package. I'm not sure that adding another makes things easier. Configuration options will need to be specified manually if you want any but I don't see a way around that as they are both package-specific and also something where distros want to differ. For dependencies there are usually language-specific registries and pkg-config for C/C++-land. Some distros (e.g. RPM-based-ones) already support specifying dependencies by the pkg-config names or library SONAMEs. There is no distro-agnostic way to specfy your dependencies except for a README as far as I know - this would be something worth specifying.

t43562 4y ago

You'll invent new standard and have N+1 standards. It's not as if package formats can't be declarative - just that some issue always turns up in package X or Y that the declarative format didn't anticipate. I think there may indeed be tools to convert these formats but in the end the devils are always in some distro-specific set of details that make life miserable. e.g. your library has some option enabled or doesn't and some other package in that distro needs it and so on and on.