No but it certainly doesn't seem good to be moving in the wrong direction either.FreeBSD isn’t POSIX / SUS compliant anyway.
If you want to rice with things, thenI’m just saying that it would be useful to have an option to not install it if you don’t want it.
rm /usr/bin/clang
rm /bin/ed
Given some packages pull in a whole gcc10, just to have a few runtime libraries, a mechanism to build more than one package from one port is desperately needed.*) But that's a different topic.Whats next? Split development libraries from packages? aka zlib, zlib-dev
Possibly a different topic. But I am again of a different idea when it comes to packages, less is better. I.e a gtk+ package should bundle all the gtk+ cruft such as pango, gobject, gconf into one package called gtk+. They never get used individually anyway. This is just modular monolith GNU crap.Given some packages pull in a whole gcc10, just to have a few runtime libraries, a mechanism to build more than one package from one port is desperately needed. But that's a different topic.
Except when they are, which is especially true for a few libraries out of a huge package with everything. The assumption that the machine running the software is also the build machine is flawed.Possibly a different topic. But I am again of a different idea when it comes to packages, less is better. I.e a gtk+ package should bundle all the gtk+ cruft such as pango, gobject, gconf into one package called gtk+. They never get used individually anyway.
Then again, from what you write here, I'm pretty sure you misunderstand the concept. I'll try again: nothing will change about base being self-contained, one repository, developed and release-engineered as a whole. And then, infrastructure for building packages is already there. Once this is officially used, all that will change is instead of distributing one huge base.txz, distribute a lot of small .txz packages with (together) exactly the same content. This just means you don't have to compile yourself any more in order to choose to NOT install some component. And that's it…As for the pkg-base, I am not entirely certain I have misunderstood the design. Just because programs are grouped into larger meta-packages with a different name doesn't mean they wont be fragmented and split at a later date.
The usecase is the OTHER way around. Software compiled with GCC needs GCC runtime libraries. This is an extreme example, but one that's relevant for many packages. Just to run a software compiled with GCC, you need to install the whole huge GCC package to have the few libraries available.Are you ever going to install the i.e compiler packages and not the runtime packages? What is the point?
So for the few gcc projects I had, to eliminate the dependency on gcc package at runtime, I just statically link the runtime in. Yes, not available for everyone but clang *is* the FreeBSD system compiler. If people go against that, that is a little bit their problemExcept when they are, which is especially true for a few libraries out of a huge package with everything. The assumption that the machine running the software is also the build machine is flawed.
Thats fine. So long as you can cat those ratty small files together and rename it base.txz I am happy. Otherwise, why are they fragmenting those files?Once this is officially used, all that will change is instead of distributing one huge base.txz, distribute a lot of small .txz packages with (together) exactly the same content. This just means you don't have to compile yourself any more in order to choose to NOT install some component. And that's it…
So, it's your fault as an end user wanting to run a software that only compiles with GCC? How could you be so stupid wanting to use it? Then live with tons of "crap" installed you never need.So for the few gcc projects I had, to eliminate the dependency on gcc package at runtime, I just statically link the runtime in. Yes, not available for everyone but clang *is* the FreeBSD system compiler. If people go against that, that is a little bit their problem
I answered this very question twice. Calling it "fragmentation" is already (at best!) misleading. Do you have any argument for forcing anyone to always install the whole base, or otherwise compile himself? How does it hurt you?Thats fine. So long as you can cat those ratty small files together and rename it base.txz I am happy. Otherwise, why are they fragmenting those files?
Yes, I know. I was being annoying to try to show that it is slightly of limited use.The usecase is the OTHER way around. Software compiled with GCC needs GCC runtime libraries.
Or get someone to fix that broken crap so it compiles with Clang. We do this for MSVC++ centric code all the time right? It is broken and needs fixing.So, it's your fault as an end user wanting to run a software that only compiles with GCC? How could you be so stupid wanting to use it? Then live with tons of "crap" installed you never need.
More strawman nonsense. It's just about not installing stuff you don't need.Ricing is something that should not be normalized
So will the installer also provide a list of kernel modules / firmware the user probably wont need and they can pluck them away?More strawman nonsense. It's just about not installing stuff you don't need.
Are you misunderstanding me on purpose? Again, I’m not saying that FreeBSD should ship without clang.No but it certainly doesn't seem good to be moving in the wrong direction either.
No, the correct approach would be something likeIf you want to rice with things, then
Code:rm /usr/bin/clang rm /bin/ed
pkg delete ed
(similarly for clang) so its (non-)presence is properly recorded in the package database, so other things that depend on it can react accordingly.It’s unlikely that there will be any issues. What kind of issues would you expect? If a 3rd-party package requires ed, it has a dependency recorded and pulls in the ed package if needed, like with any other dependency.And just remember to mention that on the mailing lists if you ever run into issues and need troubleshooting.
We already do that for quite some time.Whats next? Split development libraries from packages? aka zlib, zlib-dev
I am sure there are many who think that it should. And now (or in the future) we will have to deal with their broken installs.Are you misunderstanding me on purpose? Again, I’m not saying that FreeBSD should ship without clang.
# pkg remove compiler
For deployment it is nice to have a known base. It means in some cases, you don't even need to make a port or package. The fact that this base can now be minced up reduces the guarantee and either a big list of packages needs to be listed as a requirement or I need to make a formal port.It’s unlikely that there will be any issues. What kind of issues would you expect? If a 3rd-party package requires ed, it has a dependency recorded and pulls in the ed package if needed, like with any other dependency.
That is news to me. I'm running FreeBSD where if I install i.e zlib, I get the lib and includes. What OS are you running?We already do that for quite some time.
Some of us are old enough to remember what happened when Sun for the first time shipped SunOS without a compiler, and then required paying of extra license fees to get a compiler. Actually, the correct term is not "remember", but "still feel the pain and are still mad". So removing the compiler from the most basic OS is likely to create a strongly emotional response.And clang – well, why shouldn’t it be optional?
Completely agree. I'm running a few RPi0, and on those I would never think of doing a major compile, and disk space is at a premium, so not having the compiler and all the development libraries is sensible.In fact, when I install FreeBSD on a space-constrained machine, I remove the compiler tool chain, static libraries, include files and several other things. It would make sense to be able to de-select these in the installer if you don’t need them.
So, what problems exactly would you expect? We already have working dependency mechanisms in ports and packages.Not because I am mean but because it would generate a mess of different installs.
Did you ever create a port? Adding a dependency isn't a huge thing to do, and they work transitively.For deployment it is nice to have a known base. It means in some cases, you don't even need to make a port or package. The fact that this base can now be minced up reduces the guarantee and either a big list of packages needs to be listed as a requirement or I need to make a formal port.
So, right now, FreeBSD is just like Windows regarding the base system, but unlike Windows has a well-working package management. Then your argument is, it should still keep the drawbacks of Windows?Consider if on Windows it was possible to randomly uninstall conhost or user32.dll. You would expect all 3rd party software to gracefully handle that? FreeBSD really isn't much different. Known configurations are nice.
WITHOUT_XXX
knobs for my base. It doesn't create any problem.Not sure if that's what you're implying here, but individually upgrading packages in base isn't the point of pkg-base and shouldn't (and, I'm pretty sure, WON'T) be supported.The benefit of having a base package, would be, we have to wait for a new release to get a newer LLVM and Clang, when ports already require the latest versions. This would be a benefit of not having LLVM and Clang in base, and having it in base packages. There was an implication of having LLVM in base, but not Clang, but some ports may require that both be upgraded.
You're really beating this strawman to death.Some of us are old enough to remember what happened when Sun for the first time shipped SunOS without a compiler, and then required paying of extra license fees to get a compiler. Actually, the correct term is not "remember", but "still feel the pain and are still mad". So removing the compiler from the most basic OS is likely to create a strongly emotional response.
I doubt anything like this will happen. It's more of a fear on something that happened from somewhere else. That wouldn't fit FreeBSD's business model anyway. Also, the base has a set standard to use certain types of licenses, pkg base will be like this too or more or less like this.Some of us are old enough to remember what happened when Sun for the first time shipped SunOS without a compiler, and then required paying of extra license fees to get a compiler. Actually, the correct term is not "remember", but "still feel the pain and are still mad". So removing the compiler from the most basic OS is likely to create a strongly emotional response.
Not sure if that's what you're implying here, but individually upgrading packages in base isn't the point of pkg-base and shouldn't (and, I'm pretty sure, WON'T) be supported.
I'm not sure but don't a number of Perl, Python, Node.js dependencies compile up their native binaries during install / first use. Just installing something from PIP / CPAN will likely fail unless you have a C compiler installed.Completely agree. I'm running a few RPi0, and on those I would never think of doing a major compile, and disk space is at a premium, so not having the compiler and all the development libraries is sensible.
I wish. Sounds like it is going ahead. I personally think it is a bad decision. That said, I am still not impressed by the entirety of pkgng which seems to be an enabler of this.Well, after years of work on it (and, maybe, more years to come), some day someone will have to admit: pkg-base, killed by FUD…
Really its not. At least if it is removed you know where it stands and you can make more educated guesses about peoples setups. Either way you will now have to explicitly state "make sure to have ABC installed"Making installation default, but optional, is something completely different than removing it from base.
Do you add a dependency on xz to extract the package itself? Can I perhaps just add one dependency called "base"? This whole situation is very disappointing.Did you ever create a port? Adding a dependency isn't a huge thing to do, and they work transitively.
Time will tell. It sounds like a clusterfsck to meAll it does is give the option to NOT install something – without having to build yourself.
Yes, see https://cgit.freebsd.org/ports/tree/Mk/Uses/tar.mk#n11Do you add a dependency on xz to extract the package itself?
USES= tar:xz
.I'm still convinced you just don't understand how it works. For the example above, nothing would have to change in the port.Can I perhaps just add one dependency called "base"? This whole situation is very disappointing.
USES= tar:xz
would just automatically add that dependency on the required base package.Sunsite! I forget the full URL, but that's where you had to go to make your shiny new Sun box useful.Some of us are old enough to remember what happened when Sun for the first time shipped SunOS without a compiler, and then required paying of extra license fees to get a compiler. Actually, the correct term is not "remember", but "still feel the pain and are still mad". So removing the compiler from the most basic OS is likely to create a strongly emotional response.
Devil's advocate argument. It already is. It's just hidden from you by the fact that a bunch of sources are downloaded and checked into the src repo.In all fairness, I am fine with ralphbsz's suggestion. Even if all the packages in base are specifically tailored for him, I would rather that even for my use-case. So long as base *is* a base rather than a scatty ever changing collection of packages.
Don't know them but git won't because of the license, unless core reverse their approach on gpl.Do we getgitlite
(origitt
) in base?
From how it appears to me, we cannot build a kernel without, because we do not get a version string intouname
. But then, git requires 89 prerequiste ports - and I am not really into installing all these into a bhyve before building a kernel...