Alot of packages versus virtual bundle packages.

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 ?
 
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.

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?
 
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.
 
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.
 
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.
:)
 
Even the ports include meta-ports, like x11/kde5. Just do
Code:
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. :cool:
 
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.
 
Back
Top