Jose, the wording is indeed a bit strange but the context what Zirias said,
"pkgbase is similar to WITHOUT_* k" explains it.
"pkgbase is similar to WITHOUT_* k" explains it.
As I see it, "releasing parts individually" does not necessarily mean that they have to be on a different release mechanism or timed differently as compared to the kernel. They (i.e. the to-be-packages inside the base install) are just "released" on a per packages basis; think of it as "are made available". Updates on those packages are still to be made under the same scheme as today for the base install.These two sentences directly contradict each other.Splitting base, releasing parts individually, is and was never planned (and would make no sense, if you wanted that, you could just convert everything to ports). All pkgbase was ever about is not having to install everything if you don't need it...
To summarize:I cannot see the big advantages of packages in the base install.
While I agree that sendmail doesn't have to be in base, some MTA is required*). A working base system at least must be able to deliver local mail. A browser OTOH definitely isn't necessary for a working system.Much simpler, you could also remove functionality ports from base, like sendmail, and put them in ports.
One can also ask the question why no browser is part of base.
The current practice of distributing several tarballs (some of them even optional) already calls bullshit on that.Either there's a base or there isn't. Once "base" becomes a set of packages you can pick and choose from, there no longer is any common "base" and you descend into Linux madness.
I only see one base.txz. And extracting that is all that is needed to install the base userland in i.e a Jail or chroot.The current practice of distributing several tarballs (some of them even optional) already calls bullshit on that.
Then you won't have any kernel, cause that's in kernel.txz.I only see one base.txz.
Indeed. You don't need a kernel for a jail (presumably a perfectly good one is already running by that point).Then you won't have any kernel, cause that's in kernel.txz.
I removed some stuff. As learning experience.Either there's a base or there isn't. Once "base" becomes a set of packages you can pick and choose from, there no longer is any common "base" and you descend into Linux madness.
You say current base can be customized with compile-time knobs, as a justification for this a la carte approach. I say that customizing base under the current system requires significant knowledge and effort. You will learn a lot just from attempting this, and this knowledge will help you troubleshoot the problems you will encounter. Once it becomes easy to scramble what's in "base" lots of fools will start removing things for stupid reasons like they read on some Internet forum that removing libc would make their system faster.
Yes, the line between what should be in base and what belongs in ports is not always clear. Sometimes difficult choices have to be made which will not please everyone. That is another key difference between Freebsd and the Linuxes. These unpleasant choices are made. You'll have to do the hard work of evangelizing to change the consensus if you strongly believe something should or should not be included. Over in Linux-land you just roll your own "distro" and foist it on the world.
nooption COMPAT_FREEBSD32 # Compatible with i386 binaries
WITHOUT_LIB32=yes
Sorry officer, the keys to the safe are in the safe...The tools to install base should also be in base. E.g. /usr/bin/tar
And if you have n packages to choose from, and say you choose k of them, the possible combinations grow by n!/(k!(n-k)!).We have a kernel "package" and a userland "package" right now. You can run older userland on a newer kernel, this is one line of dependency. Once you start breaking up base, you end up with a subset of a K{n} of all n components.
Conceptually yes, but it's less fine-grained than pkgbase would be. And a key difference is, ports don't have to care about dependencies to base, because anyone building their own base is expected to be able to solve such problems.Just modify /etc/src.conf & you specify WITH or WITHOUT, does the same thing ? No ?
Actually, there are more, e.g. packages with debugging symbols, or with 32bit libraries.I guess if your definition of a base also includes kernel then there are two packages
src
repository is part of the base system, developed as a whole, and whatever is built from it is released together, no matter whether it's 9 tarballs or a few hundred .pkgs.