n0dalus wrote:
I think that person should really be you :). Your preconceptions about how things should be packaged is a bit outdated.
A few years ago there used to be monolithic packages well over 100MB that every time something small was changed the whole lot needed to be updated. Splitting up packages is a good thing. It means less install size, less bandwidth used and easier updates. The packages should have
Dream on! As long as all those subpackages are generated from the same SRPM you will save nothing and get all of them if the SRPM changes. Could be seen very nicely with X where a stoneage small program had a security bug and the _whole_ X was upgraded including the font files. And yes, X was already split in subpackages. Now that's fixed with the modular xorg but that's *not* an achievement of the packagers but of the upstream project. Where subpackes help is to limit the amount of requirements the program has. That's highly used on heavy customized servers and less so on the desktop.
I like how it's done for git in fedora extras: git is a meta package which requires all subpackages making it very easy and intuitive to get it. So having something like wine being the meta package and the actual wine subpackage being renamed to wine-core would give the user friendliness and choice for those who need it.
meaningful descriptions, and should depend on each other in a way that means you just choose what you want and the package manager will get what you need. Some time in the future (or already) the package manager may make the distinction between required packages, suggested packages and enhancement packages, making it easier for users like yourself to work out what they want.
I like how it's done for git in fedora extras: git is a meta package which requires all subpackages making it very easy and intuitive to get it. So having something like wine being the meta package and the actual wine subpackage being renamed to wine-core would give the user friendliness and choice for those who need it.
bye michael