ladar
commented
2 years ago @bodgit I excluded the xbase set (along with the other X sets) because they would add more the box download(100 megabytes for xbase), and those sets aren't inline with our goal of creating ready made CLI environments. That said, I also prefer to emphasize having a usable environment, over download size, which is why I preinstall packages I would expect to find and or use in a shell script. For example grep, sed, awk, curl, etc. But I don't think the xbase fits that either.
In a perfect world, I wouldcreate graphical variants for some of the distros (I've wanted to for awhile, but don't have the time/resources), and if there is ever a full time employee hired to work on this project, it will probably happen.
If you don't mind building your own base images, what you want is a pretty easy change. Just remove the relevant line from the http/generic.openbsd6.install.cfg file, and run ./robox.sh box generic-openbsd6-libvirt to create a box file.
Obviously change the version, and/or provider if you don't want v6 or libvirt.
As for the OpenBSD versioning issue, it's actually come up before. OpenBSD was around before the modern major, minor, patch version scheme became the norm, so I realize they do it a little different, and it doesn't match how I create and maintain the other distro boxes. But given resource/time constraints, I can't justify maintaining and rebuilding the past OpenBSD releases, like I do with Fedora/Ubuntu, so it's stayed as is. Until recently it wasn't an issue, since the only repo, generic/openbsd6 was effectively locked onto the latest distro release. But with 7.0 that changed.
If it was just me, I think the solution would be to drop the 6 and 7 from the repo names, and just have a single repo locked on the latest. That's how it works with Gentoo and Arch, since they release frequently, and I can't maintain all the past variants. But that repo name change would break everyone's scripts, so I'm hesitant to do it without more community feedback.
bodgit
Hello,
I'm trying to use your OpenBSD boxes and I'm finding it's hard to automatically install some packages because they happen to be linked against X11 libraries even though they work fine on the command line.
Would you consider just including the xbase set in the OpenBSD box which provides the X11 libraries, header files and a few other files? This does not include the actual X server itself so it doesn't make the box into a graphical one.
I would be using these boxes as automated test boxes for Puppet so having to manually find, download and unpack the xbase set every time would break the workflow.
Also, it would be really handy to have the current and previous OpenBSD release as distinct boxes, which matches the OpenBSD support/release policy. So for example I'd like to have
generic/openbsd69andgeneric/openbsd68available, but when 7.0 comes out, (assuming that's the next release), it's fine to drop the 6.8 box, etc.