Deprecating base system ftpd

What next? Removing "ifconfig" like in other OS and making it part of net-tools package? Or remove the "ping" you don't need it to boot. I personally prefer some tools to be preinstalled on the OS like sshd, ifconfig, telnet, ftp,trace,ping and so on... you never know when you going to need them but it's better to have them as part of the OS.
 
From how it appears to me, we cannot build a kernel without, because we do not get a version string into uname.
Nonsense, the only thing that's unavailable for uname is a commit count and hash. Now why is that a problem?

But then, git requires 89 prerequiste ports - and I am not really into installing all these into a bhyve before building a kernel...
Ever heard of a tiny (sic) something called flavors?
 
What next? Removing "ifconfig" like in other OS and making it part of net-tools package?
Does anyone actually read anything before spitting out polemics?

pkg-base has nothing to do with removing things from base. And btw:
https://cgit.freebsd.org/src/tree/sbin/ifconfig/Makefile?h=releng/13.0#n6 said:
PACKAGE=runtime

Not installing the base "runtime" package would effectively mean not to install base at all.
 
You know which Linux Distribution i refer to...
No. But does it really matter? pkg-base has nothing to do with splitting base in parts – it will always be the single project it is today. Building separate binary packages from this one source tree is a very different thing (and nothing you will ever find with any Linux system).
 
Addressing the meta-argument - yes, we're bikeshedding here, but it's fun bikeshedding, dammit!
Oh, very likely! ;)

I see the value of tweaking what's in that src repository to suit your needs too.
Agreed, but this already does exist. You can mince with the build scripts as you compile a custom FreeBSD userland. It sounds like Zirias already does this. Yes, granted it is currently harder than just rinsing some random packages from the install but honestly you will not want a beginner doing this anyway.

At the very least when I list all my installed packages, I don't want the output to be clogged up with packages I know are there because... well of course they are, they are in base.

It's as simple as USES= tar:xz.
And will you now need to do similar for sh? To be able to run the ./configure script?
You may find out that this list of USES you need to spam in the port will get quite long.

CMake at runtime uses a lot of hidden things in base you may not realize. Your port will now have to cater for those mad men who decided not to install a proper base.
 
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?
These are the distribution sets of FreeBSD 13.0-RC5 amd64:
Code:
-rw-r--r--  1  ftp  ftp   192282016  Apr 02 07:23  base-dbg.txz
-rw-r--r--  1  ftp  ftp   189152220  Apr 02 07:23  base.txz
-rw-r--r--  1  ftp  ftp    89978588  Apr 02 07:23  kernel-dbg.txz
-rw-r--r--  1  ftp  ftp    42371308  Apr 02 07:23  kernel.txz
-rw-r--r--  1  ftp  ftp    19242368  Apr 02 07:23  lib32-dbg.txz
-rw-r--r--  1  ftp  ftp    69986184  Apr 02 07:23  lib32.txz
-rw-r--r--  1  ftp  ftp    41361196  Apr 02 07:23  ports.txz
-rw-r--r--  1  ftp  ftp   160365292  Apr 02 07:23  src.txz
-rw-r--r--  1  ftp  ftp    13861380  Apr 02 07:23  tests.txz
The ones with -dbg in the name contain libraries for development that have debug symbols and profiling information, the others don’t. The installer asks you which of the distribution sets you want. Only the “kernel” and “base” sets are mandatory, the others are optional (and this won’t change with pkg-base).
FreeBSD has this distinction since day one (although the naming and layout changed over time).
 
These are the distribution sets of FreeBSD 13.0-RC5 amd64:
Ah, yes. I think the confusion here is: it's currently not possible to do for ports (short of workarounds like slave ports). Still, the need is there, especially if a full library (or even compiler!) package is a lot larger than just the set of runtime libraries actually needed.
 
Seriously – dd is required by the standard boot procedure

We read above: standard. I am not a developer as olli@, but I have made some non-standard
installations that would have been much more difficult not having standard tools, in which it would
have been a dream to be able to just type pkg add xxx. I think it was an error to remove slattach,
although a lot of people would say it was obsolete, insecure, primitive, etc.

And in the same fashion as a Usenix conference without Kirk and Eric is not a Usenix conference, a BSD without UFS and Sendmail is not BSD.
And UFS is a good filesystem and sendmail not worse than other MTAs. And sure, sendmail is used out
of custom, perhaps only because it is there as default, but this is not a problem, it is an advantage: one
puts energy to learn an MTA and then it is easy to use and configure. One puts energy to learn a
standard FreeBSD. FreeBSD becomes then a concept of a full OS, not of a pkg-supermarket with products
for every taste. Learning, the beginning, needs always some energy. Those that want other MTA may install it.

Those that are creative and really want to do something better, should write an new OS and leave FreeBSD
as FreeBSD. Then we have more, not less. The Unix creators did that with plan9, and plan9 is a wonderful
OS, conceptually better than Unix.
 
FreeBSD has this distinction since day one (although the naming and layout changed over time).
Ah I was referring to -dev packages not -dbg. So for example on Linux you install zlib but you don't get the C headers. You would need to install zlib-dev or zlib-devel for that.

In FreeBSD we have the base.txz which includes development files as well. For example we don't need base-dev.txz
 
So, saying nothing with a broken analogon?

Uname will always have the exact release name (13.0-RC5-p1 …), the build host and the build timestamp. What exactly do you need a commit hash and count for?

The only possible use case would be on a "stable" branch or on main/current. If you follow one of these, it always made sense to get your source directly from the repository, git didn't change anything about that.
 
So, saying nothing with a broken analogon?
It's precisely the matching analogon. As some people are indeed promoting the opinion that identification is superfluous, and anybody should be free to travel anywhere.

Uname will always have the exact release name (13.0-RC5-p1 …), the build host and the build timestamp. What exactly do you need a commit hash and count for?
Currently I dont see neither build host nor timestamp (I don't want to see these, anyway):
Code:
# uname -a
FreeBSD  12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6#9f00856c417 GENERIC  amd64
Before, it used to look like this:
Code:
$ uname -a
FreeBSD  12.2-RELEASE-p5 FreeBSD 12.2-RELEASE-p5 #0 r369523M#N1250: Sat Mar 27 [etc.etc.]
The thing starting at the last hashmark is a local add-on and reports the local patchset (you don't find that one in the official repo)! Without that the uname would now probably look like this:
Code:
# uname -a
FreeBSD  12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC  amd64
The only possible use case would be on a "stable" branch or on main/current.
Yes, then it gets really bad. Then you will gather bugreports from people and you will have no idea what code they might actually be running. And probably not even an easy way to figure that out after the fact (there are no $Id: anymore going into the code).
Oh, I forgot: you have "reproducible builds" now. So you can simply build a kernel from every commit, and compare cksum until you find the matching one.:D

But that's all not a problem with me, this is just fine along the Golgafrincham storyline. What really annoys me is that there now 12.2-RELEASE-p6#9f00856c417 is no space in between. That is ugly. What I would want to see is this:
FreeBSD 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 81526c74d9c#9f00856c417 GENERIC amd64
 
It's precisely the matching analogon. As some people are indeed promoting the opinion that identification is superfluous, and anybody should be free to travel anywhere.
No, it's silly. 12.2-RELEASE-p6 is all the identification you need, there's only one commit linked to it, short of
local patchset
yeah, right – then add whatever you want to mark that. So, where exactly would be the problem with NOT using git? You didn't get a revision number in uname either when not using svn before.
Yes, then it gets really bad. Then you will gather bugreports from people and you will have no idea what code they might actually be running.
I don't think anyone who isn't able to either use git on a default branch or track what exactly he built himself would be qualified submitting any helpful bugreport about CURRENT. Same thing, nothing substantial changed compared to svn.

This all looks like a lot of "I don't like change" complaints.

Just a side note, I wonder how you build your system to get uname -a output like this. Mine for example looks like this (and always did, on 12.x, built from subversion, ...)
Code:
FreeBSD nexus.home.palmen-it.de 13.0-RC5 FreeBSD 13.0-RC5 #14
config-n244728-2f274dd5c94: Fri Apr  2 15:52:15 CEST 2021
root@builder.home.palmen-it.de:/usr/obj/usr/src/amd64.amd64/sys/DESKTOP
amd64
Newlines added for readability, the only thing that changed with GIT is the config-n244728-2f274dd5c94 part. There was only a revision number before, now I have <branch>-<count>-<hash>. Yes, config is a local branch here, containing my kernel configurations.
 
Very interesting.
For example, this is one of my boxes (yes, I still have 32bit machines):
Code:
$ uname -a
FreeBSD myhost.mydomain 12.2-STABLE-20210131 FreeBSD 12.2-STABLE-20210131 #0: Tue Feb  2 21:13:06 CET 2021     olli@myhost.mydomain:/usr/obj/usr/src/i386.i386/sys/CANTARO  i386
The date stamp -20210131 is a local addition of mine (via $BRANCH_OVERRIDE that is picked up by make kernel). The rest is standard. When FreeBSD used Subversion, I also had the SVN revision number in there because it was useful for me. Unfortunately, Git doesn’t support revision numbers, and the Git hashes are useless, so I don’t put them in uname.

Most of the time, the information from uname -r is all I need; uname -a is much too verbose.
Code:
$ uname -r
12.2-STABLE-20210131
Actually I have a shell function that calls uname -rsm when I enter just uname without arguments. Output looks like this:
Code:
$ uname
FreeBSD 12.1-STABLE-20200612 amd64
$ grep uname ~/.zshrc
uname () { if (( $# == 0 )); then set -- -rsm; fi; command uname "$@"; }
 
Git doesn’t support revision numbers, and the Git hashes are useless, so I don’t put them in uname.
Actually, they serve the same purpose. E.g. assuming you have a hash b7fbdb5042c in your uname output (a commit that actually exists on releng/13.0), you could inspect exactly what changed since then with git diff b7fbdb5042c.

FreeBSD also adds a "commit count", seemingly just to have this increasing number ppl were used to, but that I'd consider somewhat useless, as it can't identify a commit ;)

edit: BTW, your uname -a output looks like mine. So, still wondering what PMc is doing here ;)

Actually I have a shell function that calls uname -rsm when I enter just uname without arguments.
THAT looks like a nice idea! I'd personally add -i flag, having multiple kernel configs, I might want to verify the correct one is installed.
 
Ah I was referring to -dev packages not -dbg. So for example on Linux you install zlib but you don't get the C headers. You would need to install zlib-dev or zlib-devel for that.

In FreeBSD we have the base.txz which includes development files as well. For example we don't need base-dev.txz
Ok, I see, so we were talking about slightly different things.

Actually, the naming conventions are somewhat unfortunate. Strictly speaking, the -dbg sets are intended to be used by developers (that’s why I called them development sets). They are not required for normal users who just want to build stuff (e.g. /usr/src or /usr/ports). In contrast, the -dev packages are required when building things, so they’re not only for developers, but also for normal users, unless you install binary packages only and never build anything yourself.

By the way, there are a few nasty things. For example, there are binary packages that compile some stub files during installation. These require a compiler, even though they are binary packages. If the compiler is optional (at some point in the future, not yet with pkg-base), then such packages will have a dependency on the compiler package. We already have this today for ports that require a certain version of the compiler that might be different from the version in base.
 
Actually, they serve the same purpose. E.g. assuming you have a hash b7fbdb5042c in your uname output (a commit that actually exists on releng/13.0), you could inspect exactly what changed since then with git diff b7fbdb5042c.
I know that, but my use case for SVN revision numbers depended on the fact that they are consecutive. That’s not the case for Git hashes.

FreeBSD also adds a "commit count", seemingly just to have this increasing number ppl were used to, but that I'd consider somewhat useless, as it can't identify a commit ;)
Oh, I didn’t know about that. I’ll have to look how to get at that count. Thanks for the hint.
 
my use case for SVN revision numbers depended on the fact that they are consecutive.
So, there actually is a use case for some :-/

Well, in my output above, in config-n244728-2f274dd5c94, n244728 is the revision count. It counts locally, so it will only work correctly with a full clone. I guess that's one of the reasons shallow clones aren't officially recommended ;)
 
No, it's silly. 12.2-RELEASE-p6 is all the identification you need, there's only one commit linked to it, short of
In this case, yes.

yeah, right – then add whatever you want to mark that. So, where exactly would be the problem with NOT using git? You didn't get a revision number in uname either when not using svn before.
svn was in base.

But then, even *IF* git were in base (which, as was mentioned here, does not work because it comes from smelly fish-eating bird), you would not easily get a useful revision number from it.

Because: it considers a checkout containing local patches as just fine for the purpose, and consequentially switches to "reproducibe build". *IF* git were installed, it might just spit out the 9f00856c417 commit-id and be done with it - which is a local one, and not to be found in the official repo!

I don't think anyone who isn't able to either use git on a default branch or track what exactly he built himself would be qualified submitting any helpful bugreport about CURRENT. Same thing, nothing substantial changed compared to svn.
It concerns STABLE also.

This all looks like a lot of "I don't like change" complaints.
Do that to whomever, but not to me. It doesn't work here.

I spent time getting that git thing to do something useful, and it's troublesome enough.

Just a side note, I wonder how you build your system to get uname -a output like this. Mine for example looks like this (and always did, on 12.x, built from subversion, ...)
What's different between mine and that? I have no hostname configured, so 2nd field is empty. git is not isntalled, so there is no commit-id from there - but my own add-on fetches and inserts that.

And it seems You have set WITHOUT_REPRODUCIBLE_BUILD in /etc/src.conf, so that the date-stamp+email+localpath gets added even without the checkout being dirty.
 
svn was in base.
So what? git-tiny is a tiny package. Complaint-mode?
But then, even *IF* git were in base (which, as was mentioned here, does not work because it comes from smelly fish-eating bird), you would not easily get a useful revision number from it.
You get both, a revision count (what's your usecase here?) AND a commit hash.
Because: it considers a checkout containing local patches as just fine for the purpose, and consequentially switches to "reproducibe build".
I don't know what you do to your source, but "reproducible build" is always off by default:
*IF* git were installed, it might just spit out the 9f00856c417 commit-id and be done with it - which is a local one
Which is exactly the expected behavior. You're building from a local commit, so if you can't identify what you built with that, there seems to be a different problem.
Do that to whomever, but not to me. It doesn't work here.
Complaining about change is all you're doing here. At least as long as you can't explain what's the actual problem with things you complain about. Your wording above is also a strong indicator.
And it seems You have set WITHOUT_REPRODUCIBLE_BUILD in /etc/src.conf
No. This is off by default. But good to know that's the option leading to your unusual output.
 
Back
Top