Metapackage support in HaikuDepot

That would just open the floodgates. “Why not a Graphics Edition? Multimedia Edition? Office edition?” And before we know it we’re in the same distro hell as Linux. This is a tiny community, and we cannot afford to be divided.

What would be easy to implement is a small collection of metapackages. Install devpack-1.0-1-any.hpkg and it installs all (or a good selection of) development-related applications. The hpkg itself is little more than an .PackageInfo file with a list of dependencies.

Make about 6-10 of those, throw in a Preference app, and you can easily transform a standard installation into the Haiku box of your dreams.

If I can find the time, I’ll cook up a proof-of-concept.

3 Likes

BeOS development tools (DevTools) was a decent packaged example of this (basically, BeOS Developer Edition). You can supply headers, docs, code examples, libs, etc).

Maybe, migrate the BeOS 5.x DevTools into a Haiku version?

1 Like

I second the meta package proposal. It would be nice to make those dependencies optional and let the user decide which they want to install, maybe?

Having metapackages for certain things is great.
Having metapackages to install three or four different IDEs is not. Since installing an application is easy and quick, the new user/developer can just install what he needs and try a couple ones until he finds what fits him better.

2 Likes

Plus, it’s not just wasted space. A bigger disadvantage in my book is that if stuff gets updated, I have to download and wait until, for example, all those Qt or KDE dependencies have trickled down the line…
Sure, I could (and would) deinstall what I don’t need - though, the main package is easy, good luck finding all the right dependencies. But why install all the stuff in the first place? IMO that’s backwards…

OTOH, nobody forces me to use those meta-package behemoths. So, go right ahead, but don’t make them “official Haiku flavours”.

4 Likes

The problem with these metapackages is that not everybody uses the same tools for development. You would have to include a lot of tools that not everybody needs.
I think as long as we have working categories in HaikuDepot (do we? I have no idea, I’m strictly pkgman :wink: ) we are good. If someone wants to set up a dev environment they can fire up HaikuDepot, go to the Development category and have all the tools at their hands for installing.

2 Likes

I know that switching Java versions globally is as easy as installing a metapackage in HaikuDepot. Having a subset of packages independent of HPKG packages selectable from HaikuDepot with their own sub-installer seems redundant.

My 2 cents, I don’t think we should support such metapackage(s) at haikuports, that would mean having packages available separate and in one or more metapackage(s), which would increase the (precious) disk space needed to store these.
Also which packages would those metapackage(s) supply, I guess that would differ for each individually ?

1 Like

I think metapackages should only be a set of related packages. not something that actually depends on anything.

I.e You can say “I want to see the kde set” and the package management would ask you which apps from that you want to install, and offer some context what works together and such. But in the end for the package management you should only have installed 3-4 more applications

For the KF6 frameworks that accounts (with the _devel packages) for almost 140 packages, that’s crazy as you don’t want them all (or need them all) :rofl:

That’s why I only want them shown as a collection, and of those only gui apps you can interact with. (so no _devel or lib or _tools or debuginfo)