Preconfigured Xorg install in base system

P

Pecka

Both NetBSD and OpenBSD offers an install option to get Xorg with a basic window manager out of the box.

Wouldn't it be convenient if FreeBSD also adopted this?
 
No and Xorg is dead didn't you hear? I don't want wayland in base either.
More stuff needs to come out and go to ports tree.
 
FreeBSD used to have a base Xorg (around FreeBSD 6 I believe). It was removed because keeping it separate in ports was a more flexible design once upstream Xorg became a modular monolith.

That said, netbsd also has modular Xorg in its ports (https://wiki.netbsd.org/pkgsrc/how_to_install_modular_xorg/).

A while back, I thought it *was* more convenient when it was in base. However these days Xorg is a little messy so I do recommend keeping it separate. Perhaps once Linux is no longer dependent on Xorg and is out of the picture, it can get cleaned up again and make its way back into base. Though I personally feel Xenocara will be closer to what we want by then.
 
kpedersen said:
FreeBSD used to have a base Xorg (around FreeBSD 6 I believe).
Click to expand...
Nope, don't think it was ever included. I've been building X (which was XFree86 back in those days) from ports since I started with FreeBSD 3.0. Around the 6 era they swapped Xfree86 for Xorg. We did use to have Perl in the base though.

x11/XFree86
 
SirDice said:
Nope, don't think it was ever included. I've been building X (which was XFree86 back in those days) from ports since I started with FreeBSD 3.0.
Click to expand...
It was around the 6.x era when it changed I believe. However in sysinstall Xorg wasn't presented as a port or package. Luckily I managed to track down an old screenshot:

sysinstall-3.jpg


So there was a base and a kernel. But there was also ports, local additions collection (packages) and a separate X.Org distribution.

This lead me to believe it was in a base-x.tgz archive in dists. However, that was not the case; they weren't provided like that back in the day.

So possibly the X.Org "distribution" simply installed a bunch of packages from the installer?
 
kpedersen said:
So possibly the X.Org "distribution" simply installed a bunch of packages from the installer?
Click to expand...
Should be possible to verify this from the source ? but it certainly makes sense: Back then, the separation of base and ports was less strict than today, probably because distribution on physical media was still a relevant thing.

But we really shouldn't go back there. It would block certain changes in ports from happening before EOL of a specific FreeBSD release (like e.g. removing or renaming a port that's part of XOrg).
 
If I recall correctly you could select it during the installer. I have a 4 disc jewel case with FreeBSD 3.1 in front of me. Disk 1 (CD) is the installation boot CD, it has some packages and X11 included on the disk (not part of the base). Second disk has a live filesystem, CVS repository and web pages (handbook+articles perhaps?). Third and forth disk has packages and ports.

Either way, even if you installed X11 from the installer, you still would need to configure it. It wasn't 'pre-configured', and it certainly didn't work out of the box.
 
this is something may be placed in FAQ. :rolleyes:
NO, don't want that.
 
jmos said:
I think it's clear enough.
Click to expand...
It underlines again that's not that hard to set up X,
but I find nothing about "why not having X/GUI/DE/WM by default",
which in different variations come up nearly every couple of weeks.
 
SirDice said:
you still would need to configure it. It wasn't 'pre-configured', and it certainly didn't work out of the box.
Click to expand...
If even.
In those days (I don't know when X became to be set up that easily and automatically. I missed this, was on Windows then. app 10y ago?)
we were happy to see even the black&white background of pure X without any wm at all.
Then we had to fumble manually with modlines and geometries to get the screen matches the monitor, without too much distortions or flickering, worrying about killing the tube... ?
 
Profighost said:
It underlines again that's not that hard to set up X,
but I find nothing about "why not having X/GUI/DE/WM by default",
which in different variations come up nearly every couple of weeks.
Click to expand...
I think if that point was actually needed in the FAQ it should be simply "No Xorg is not in the installer by default. Here are some search terms for you to use to find out why"

It does get a bit tedious; almost as if the ones asking those questions don't do a search first or have other intentions.

My memory matches SirDice you could purchase disc sets from FreeBSD Mall or Walnut Creek that had extra stuff on them. It was nice because that was all before everyone had residential broadband so your internet connection was a dialup POTS line. You could select the extra distributions, installer would prompt you to swap the discs and yes you still had to go through configuring everything yourself. You really learned about modelines and monitor specs too.
 
Profighost said:
but I find nothing about "why not having X/GUI/DE/WM by default",
Click to expand...

Yep, maybe having some docs about the reasoning you could refer to would help. I repeated my own reasoning several times in several forms (and I assume it's shared by some), most important point IMHO is the clear separation of base and ports. Dependencies should only exist in one direction (ports -> base), never in the opposite one (base -> ports), but that's what would happen offering options to install "X and whatever" in the base installer. And these dependencies would, in the worst case, block ports from moving forward.

So, simple as that: the advantage of fully independent ports (for everyone) outweighs the slight gain in comfort only (only for desktop users).
 
mer said:
My memory matches @SirDice you could purchase disc sets from FreeBSD Mall or Walnut Creek that had extra stuff on them. It was nice because that was all before everyone had residential broadband so your internet connection was a dialup POTS line.
Click to expand...
I remember downloading the ISO for 3.0 or 3.1 on a 64Kbps ISDN connection. It took all weekend, only to fail at around 97% Sunday evening. Oh, and there was no 'resume'. This is what prompted me to buy the CD set. Local bookstore actually had it on sale. Some time later that bookstore also had the "FreeBSD 4.0 power pack". It was a printed copy of the handbook and a collection of CDs. I still have that one too, somewhere.
 
mer said:
if the ones asking those questions don't do a search first or have other intentions.
Click to expand...
yeah. Not even reading FAQ.
I have very high respect for SirDice.
I would not have his patience to answer the same questions over and over again, while at the same time staying cool, and reasonable.

?
 
zirias@ said:
is the clear separation of base and ports.
Click to expand...
I agree.
But in my eyes the point is way more shallow as you - correctly - described.
IMO it's because "ports" is not always ment to be used for the ports per se,
but used and understood as for "FreeBSD software packages" in general,
causing misunderstandings.
 
Power Paks and all the other bundles. I got rid of all mine a while ago, I had sets from at least 3, 4, 5 and 6.
I would have kept them if I knew they would useful in settling historical arguments.

Ports, as a generic term. I've always understood/used it as meaning "Ports Tree" or the acutally source for third party software.
Package, as a generic term. Again, I've always used it as "a binary thing built from a Ports Tree".

But newcomers may not have the knowledge yet to understand the subtle difference and realize they are "the same thing only different".
 
mer said:
Ports, as a generic term. I've always understood/used it as meaning "Ports Tree" or the acutally source for third party software.
Click to expand...
The actual source is typically referred to as distfiles. They get saved in /usr/ports/distfiles, hence the name. Each port also has a distinfo file, that contains the various source archive names and their hashes.
 
Hm.

SirDice is right, but: the ports tree itself is "source" as well. Not the source of the packaged software, but the source of all the mechanisms to build packages (which includes fetching these distfiles, extracting them, configuring build options, patching "upstream" source if necessary, actually running the build, installing to some staging area, creating a binary package from there, and possibly lots of other things....)

So, after all, about ports and packages:
mer said:
"the same thing only different".
Click to expand...
This isn't exactly wrong, it's kind of a correct simplification ? Ports are the infrastructure to build packages, official packages are ports built with all-default options.
 
  • Like
Reactions: mer
Yes, one thing newbies don't quite understand is where the packages come from. I've seen some new people ask on the forums when they get uploaded by upstream. They're not uploaded by anyone. It all starts with a port in the ports tree. The port builds the package, the build clusters use devel/poudriere for this. You can keep track of their build status on https://pkg-status.freebsd.org/. If a port fails to build the maintainer is automatically contacted and sent the details of failure. There's also a convenient website that tracks those build issues: https://portsfallout.com/

One thing that trips me up is when a port is skipped because one or more dependencies failed to build. Skipped ports aren't reported to the maintainer or to portsfallout.
 
SirDice said:
One thing that trips me up is when a port is skipped because one or more dependencies failed to build. Skipped ports aren't reported to the maintainer or to portsfallout.
Click to expand...
IMHO that's fine, it would be massive spam, and the only one in a position to solve the problem is the maintainer of the failing port anyways.

But recently, someone on here asked why the vscode package was missing. Turned out it's because the electron port it depends on is currently blacklisted on the builders. Of course there's a reason, there were problems building it, even running into timeouts. But still, what happened here is not transparent at all ... (in contrast to failing builds, sure, you need some knowledge, but you can analyze it). Therefore I opened PR 270565 about it hoping someone comes up with a more transparent solution for such cases.
 
zirias@ said:
IMHO that's fine, it would be massive spam, and the only one in a position to solve the problem is the maintainer of the failing port anyways.
Click to expand...
Yes, agree with that. I only maintain one port and sometimes a dependency does fail. I don't want to get spammed with issues I can't do anything about anyway.

It usually trips me up when I try to answer "why isn't package XYZ available?" on the forums. First thing I check is Freshports, and from there portsfallout (click on the "radio-active" icon). But skipped ports aren't reported on portsfallout. So I have to check pkg-status. And the interface of that can be quite daunting, it took me a while to understand where I had to click to get the information I needed.
 
SirDice said:
It usually trips me up when I try to answer "why isn't package XYZ available?" on the forums. First thing I check is Freshports, and from there portsfallout. But skipped ports aren't reported on portsfallout. So I have to check pkg-status. And the interface of that can be quite daunting, it took me a while to understand where I had to click to get the information I needed.
Click to expand...
I see. And I agree, although you can access all the poudriere logs, searching this stuff manually to identify why some port was skipped is pretty cumbersome.

So, another thing where transparency towards the user could be improved. Don't spam maintainers with mail for stuff they can't do anything about anyways, but DO record when a port is skipped, including the reason WHY it's skipped, that's available from poudriere anyways. This sounds like a nice idea, maybe bring it to the mailing lists?
 
You must log in or register to reply here.
Back
Top