# Alot of packages versus virtual bundle packages.



## Alain De Vos (Oct 25, 2021)

I currently have 370 "R-cran" packages and 570 "python" packages installed.
Would it be not a good idea to have some "virtual bundle" packages which packages all these packages ?
Something like "all-python" or "all-R-cran".
And these "all" contains the ones which are not broken and don't have no mutual conflicts ?


----------



## SirDice (Oct 25, 2021)

Alain De Vos said:


> Would it be not a good idea to have some "virtual bundle" packages which packages all these packages ?


That's a so-called "meta-port", it doesn't include anything of itself, it simply depends on a list of other ports. x11/xorg for example is a meta-port, x11/kde5 is a meta-port, etc.



Alain De Vos said:


> And these "all" contains the ones which are not broken and don't have no mutual conflicts ?


Who's going to maintain that list? You?


----------



## mer (Oct 25, 2021)

Similar to say the KDE/other DEs or Xorg meta port?
In general I think meta-ports are good, useful but one runs into the question "what should be included in the default" (basically the choice of default editor argument).
If one looks at say python ports, they seem scattered across different categories, like net or sysutils.  Some probably overlap in functionality or conflict with each other;  that makes it difficult to do an "all" meta port.

I'm not saying there is no merit in your idea, but I'm not sure it's really practical.
I try to go through packages installed and see if I really need them or not.  Look at the list of installed things, then go and do reverse-depends on them to see "who uses this".

Reinstalling from scratch is one way to clean out unused things.  Like moving houses every 5 years.

Ha, I picked the same two examples as SirDice.


----------



## SirDice (Oct 25, 2021)

mer said:


> Ha, I picked the same two examples as @SirDice .


They're obvious candidates to use as an example of a meta-port


----------



## jbo (Oct 25, 2021)

SirDice said:


> They're obvious candidates to use as an example of a meta-port


There's also math/octave-forge amongst others


----------



## SirDice (Oct 25, 2021)

Yeah, there's a whole bunch of them because a meta-port is quite useful to install a collection of ports/packages at once. Some people even make their own meta-ports.


----------



## mer (Oct 25, 2021)

And with a meta-port, the question is always "what to include as the default".
Seems like a simple question:
"Include what you need"
Well, what "you need" may not be what "I need" or what "She needs".
Examples:
there is an xorg meta and an xorg-minimal meta.  Over time what is included in the xorg-minimal has changed.

So if one commits to using packages, you are comitting to whatever the defaults are for every package.
If you don't like those defaults, you are comitting to building ports with your options (for some or most or all).
Pick your poison.


----------



## astyle (Oct 26, 2021)

Even the ports include meta-ports, like x11/kde5. Just do

```
cd /usr/ports/x11/kde5
make config # Make your selections
make && make install
```
What I do find a bit annoying is that Perl/Python/R/Ruby/PHP all have their own module repos, a *subset of that repo* is actually in FreeBSD ports. So if I want a module that is a bit more up to date than what the ports tree offers, I potentially have a problem on my hands. Do I wait for the ports tree to slurp in the  module update, do I go with the older version from the ports tree, or do I risk a mess by installing the exact same module from the language project's repo?

The point of my questions is basically that I'm questioning the need to put in the effort to convert Perl or Python modules into proper FreeBSD packages/ports. Sure, some of them are quite useful, and (IMHO) should probably be part of the default install of the port/package or a Makefile option. But if a port/package has a dependency on a Python module that is in the Python repo, but is clearly not in FreeBSD ports... Then I would propose that the workaround should be coded into the port's Makefile.


----------



## mer (Oct 26, 2021)

astyle that is an interesting conundrum.  I don't know the right answer, but it's definitely a hard thing to figure out.  Initial install of X is from FreeBSD pkgs, adding "packages of X" you use the command "X.install package" which looks at a set of repos for X which are not FreeBSD pkg repos.

I guess what one could do is:
If you need X.package, do "pkg search X.package" to see if there is a port already.  If so, then do pkg install X.package.  If not then do X -installcommand package.


----------

