New FVWM! Transition, initial steps

I have been using FVWM as my primary desktop for most of the last nearly twenty years if it has been around that long.  Within the last few years I have customized more and more of the various menus and other effects of my desktop.  I haven't configured anything too crazy, it doesn't look or act like windows, or any other desktop.  Mostly I made adjustments to how various common programs look, how their window is styled, and setup a number of conveniences in the menus or simple .fvwmrc embedded scripts.

A short time ago, I just saw FVWM3 scroll across my ports tree update output, and so I had to peek at freshports to see what it was about.  From there, I went to the FVWM3 webpage to peruse its change logs and readme files and other prliminary documentaion on the site.  One specific thing made me smile, the inclusion of a FreeBSD originated file somewhere in the mix.  The list of changes and bug fixes is quite impressive.  I have not had significant difficulties with FVWM except for struggling somewhat to include any bit of shortcut automation in the .fvwmrc file, or when any certain game needs vsync but I have no idea how to set that up or do what is needed to satisfy that complaint from the game (Veloren).

I saw mention in the commit message for FVWM3 something about M4 being left behind in favor of Go, but aside from this seeming to be about modules, I couldn't find anything more specific or descriptive about it.  The old (current FVWM2) configuration file and methods will be temporarily grandfathered in, which is very nice for the transition period.  I am mildly hesitant to switch as I have occasionally had drastic troubles with graphics in general in the past.  I can certainly maintain both builds in poudriere, and choose which one to keep installed.  This will leave me a fallback if anything catastrophic happens and I somehow cannot use FVWM3 at all, especially if it is something beyond my direct control.  My other concern is how exactly the new .fvwmrc file will be organized, structured, and how I will setup anew much of what I have now.  What I would be very pleased to see would be a more automated, transparent, or FVWM method to reach the .desktop files or similar, and how I could have any built menu reflect the up to the moment installed applications.  I tend to update software on my system as something to do, with poudriere it is much less invasive or disruptive for the most part.  There are still those rare times when something fails to build, then pkg does only half the job, removing the old but being unable to replace it with the new.  

Now we get ready to put poudriere on task to build this new FVWM3 along with the semi-standard X11 environment software for good measure and also just in case, to have a proper bulk build though quite small in comparison to my usual.  Instead, I decided to get an all-depends-list for FVWM3.  

make -C /usr/ports/x11-wm/fvwm3 all-depends-list > fvwm3-and-dependents

/usr/ports/ports-mgmt/pkg
/usr/ports/textproc/rubygem-asciidoctor
/usr/ports/lang/ruby30
/usr/ports/devel/libffi
/usr/ports/devel/ccache
/usr/ports/print/indexinfo
/usr/ports/misc/dejagnu
/usr/ports/devel/gmake
/usr/ports/lang/expect
/usr/ports/devel/autoconf
/usr/ports/devel/m4
/usr/ports/print/texinfo
/usr/ports/misc/help2man
/usr/ports/lang/perl5.32
/usr/ports/devel/p5-Locale-libintl
/usr/ports/converters/libiconv
/usr/ports/converters/p5-Text-Unidecode
/usr/ports/textproc/p5-Unicode-EastAsianWidth
/usr/ports/devel/ncurses
/usr/ports/devel/pkgconf
/usr/ports/devel/kyua
/usr/ports/devel/lutok
/usr/ports/lang/lua54
/usr/ports/devel/libedit
/usr/ports/databases/sqlite3
/usr/ports/lang/tcl86
/usr/ports/devel/autoconf-wrapper
/usr/ports/devel/automake
/usr/ports/security/libressl
/usr/ports/textproc/libyaml
/usr/ports/math/gmp
/usr/ports/devel/libunwind
/usr/ports/devel/ruby-gems
/usr/ports/lang/python39
/usr/ports/devel/readline
/usr/ports/x11/libICE
/usr/ports/x11/xorgproto
/usr/ports/devel/xorg-macros
/usr/ports/x11/xtrans
/usr/ports/x11/libX11
/usr/ports/x11/libxcb
/usr/ports/x11/xcb-proto
/usr/ports/textproc/libxml2
/usr/ports/devel/libpthread-stubs
/usr/ports/x11/libXau
/usr/ports/x11/libXdmcp
/usr/ports/x11/libXext
/usr/ports/x11/libXrandr
/usr/ports/x11/libXrender
/usr/ports/x11-toolkits/libXt
/usr/ports/x11/libSM
/usr/ports/x11/libXcursor
/usr/ports/x11/libXfixes
/usr/ports/x11-fonts/libXft
/usr/ports/print/freetype2
/usr/ports/archivers/brotli
/usr/ports/devel/libtool
/usr/ports/graphics/png
/usr/ports/x11-fonts/fontconfig
/usr/ports/devel/gperf
/usr/ports/devel/meson
/usr/ports/devel/py-setuptools
/usr/ports/devel/ninja
/usr/ports/devel/py-pytest-xdist
/usr/ports/devel/py-setuptools_scm
/usr/ports/textproc/py-toml
/usr/ports/devel/py-pytest
/usr/ports/devel/py-atomicwrites
/usr/ports/devel/py-attrs
/usr/ports/devel/py-coverage
/usr/ports/devel/py-hypothesis
/usr/ports/devel/py-sortedcontainers
/usr/ports/math/py-numpy
/usr/ports/lang/gcc10
/usr/ports/devel/binutils
/usr/ports/math/mpfr
/usr/ports/math/mpc
/usr/ports/lang/cython
/usr/ports/math/cblas
/usr/ports/math/suitesparse
/usr/ports/devel/cmake
/usr/ports/textproc/py-sphinx
/usr/ports/textproc/py-sphinxcontrib-applehelp
/usr/ports/textproc/py-sphinxcontrib-devhelp
/usr/ports/textproc/py-sphinxcontrib-jsmath
/usr/ports/textproc/py-sphinxcontrib-htmlhelp
/usr/ports/textproc/py-sphinxcontrib-serializinghtml
/usr/ports/textproc/py-sphinxcontrib-qthelp
/usr/ports/devel/py-Jinja2
/usr/ports/textproc/py-markupsafe
/usr/ports/devel/py-babel
/usr/ports/devel/py-pytz
/usr/ports/textproc/py-pygments
/usr/ports/textproc/py-docutils
/usr/ports/textproc/py-snowballstemmer
/usr/ports/textproc/py-pystemmer
/usr/ports/textproc/py-alabaster
/usr/ports/graphics/py-imagesize
/usr/ports/www/py-requests
/usr/ports/security/py-certifi
/usr/ports/textproc/py-chardet
/usr/ports/devel/py-pytest-runner
/usr/ports/dns/py-idna
/usr/ports/net/py-urllib3
/usr/ports/archivers/py-brotlipy
/usr/ports/devel/py-cffi
/usr/ports/devel/py-pycparser
/usr/ports/net/py-pysocks
/usr/ports/security/py-cryptography
/usr/ports/devel/py-six
/usr/ports/security/py-cryptography-vectors
/usr/ports/devel/py-iso8601
/usr/ports/devel/py-pretend
/usr/ports/security/py-openssl
/usr/ports/devel/py-flaky
/usr/ports/devel/py-nose
/usr/ports/devel/py-genty
/usr/ports/devel/py-mock
/usr/ports/security/ca_root_nss
/usr/ports/security/py-trustme
/usr/ports/devel/py-pytest-cov
/usr/ports/security/py-service_identity
/usr/ports/devel/py-pyasn1-modules
/usr/ports/devel/py-pyasn1
/usr/ports/devel/py-pytest-timeout
/usr/ports/misc/py-pexpect
/usr/ports/sysutils/py-ptyprocess
/usr/ports/devel/py-pytest-freezegun
/usr/ports/devel/py-freezegun
/usr/ports/devel/py-dateutil
/usr/ports/databases/py-sqlite3
/usr/ports/www/py-tornado
/usr/ports/devel/py-pytest-mock
/usr/ports/devel/py-packaging
/usr/ports/devel/py-pyparsing
/usr/ports/www/py-html5lib
/usr/ports/converters/py-webencodings
/usr/ports/devel/py-typed-ast
/usr/ports/ftp/curl
/usr/ports/www/libnghttp2
/usr/ports/archivers/zstd
/usr/ports/archivers/liblz4
/usr/ports/sysutils/coreutils
/usr/ports/textproc/expat2
/usr/ports/shells/bash
/usr/ports/devel/bison
/usr/ports/devel/jsoncpp
/usr/ports/devel/libuv
/usr/ports/security/rhash
/usr/ports/archivers/libarchive
/usr/ports/archivers/lzo2
/usr/ports/math/metis
/usr/ports/math/blas
/usr/ports/math/lapack
/usr/ports/devel/py-pympler
/usr/ports/devel/py-zope.interface
/usr/ports/devel/py-pluggy
/usr/ports/devel/py-py
/usr/ports/devel/py-wcwidth
/usr/ports/devel/py-more-itertools
/usr/ports/devel/py-pip
/usr/ports/textproc/py-furo
/usr/ports/www/py-beautifulsoup
/usr/ports/www/py-soupsieve
/usr/ports/devel/py-lxml
/usr/ports/textproc/libxslt
/usr/ports/security/libgcrypt
/usr/ports/security/libgpg-error
/usr/ports/textproc/py-sphinx-inline-tabs
/usr/ports/devel/py-csv23
/usr/ports/devel/py-invoke
/usr/ports/devel/py-pytest-rerunfailures
/usr/ports/devel/py-yaml
/usr/ports/devel/py-scripttest
/usr/ports/devel/py-tox
/usr/ports/sysutils/py-filelock
/usr/ports/devel/py-virtualenv
/usr/ports/textproc/py-sphinx_rtd_theme
/usr/ports/textproc/py-towncrier
/usr/ports/devel/py-click
/usr/ports/devel/py-incremental
/usr/ports/www/py-werkzeug
/usr/ports/devel/py-watchdog
/usr/ports/devel/py-pathtools
/usr/ports/devel/py-argh
/usr/ports/net/py-eventlet
/usr/ports/dns/py-dnspython
/usr/ports/devel/py-greenlet
/usr/ports/devel/py-wheel
/usr/ports/devel/mercurial
/usr/ports/devel/git
/usr/ports/devel/subversion
/usr/ports/security/gnupg
/usr/ports/security/libassuan
/usr/ports/security/libksba
/usr/ports/devel/npth
/usr/ports/security/pinentry
/usr/ports/security/pinentry-tty
/usr/ports/devel/apr1
/usr/ports/databases/gdbm
/usr/ports/databases/db5
/usr/ports/java/openjdk7
/usr/ports/archivers/zip
/usr/ports/archivers/unzip
/usr/ports/print/cups
/usr/ports/devel/xdg-utils
/usr/ports/textproc/minixmlto
/usr/ports/textproc/docbook-xsl
/usr/ports/textproc/xmlcatmgr
/usr/ports/textproc/docbook
/usr/ports/textproc/docbook-sgml
/usr/ports/textproc/iso8879
/usr/ports/textproc/docbook-xml
/usr/ports/textproc/xmlcharent
/usr/ports/textproc/sdocbook-xml
/usr/ports/textproc/html2text
/usr/ports/misc/hicolor-icon-theme
/usr/ports/x11/xprop
/usr/ports/x11/xset
/usr/ports/x11-toolkits/libXmu
/usr/ports/print/libpaper
/usr/ports/java/bootstrap-openjdk6
/usr/ports/java/java-zoneinfo
/usr/ports/audio/alsa-lib
/usr/ports/x11/libXi
/usr/ports/x11/libXtst
/usr/ports/java/javavmwrapper
/usr/ports/x11-fonts/dejavu
/usr/ports/x11-fonts/mkfontscale
/usr/ports/x11-fonts/libfontenc
/usr/ports/databases/mysql80-client
/usr/ports/devel/llvm11
/usr/ports/textproc/py-recommonmark
/usr/ports/textproc/py-CommonMark
/usr/ports/devel/py-future
/usr/ports/devel/swig
/usr/ports/devel/pcre
/usr/ports/devel/libevent
/usr/ports/devel/icu
/usr/ports/devel/protobuf
/usr/ports/devel/googletest
/usr/ports/textproc/groff
/usr/ports/print/psutils
/usr/ports/print/gsfonts
/usr/ports/textproc/uchardet
/usr/ports/textproc/utf8proc
/usr/ports/www/serf
/usr/ports/devel/scons
/usr/ports/sysutils/py-execnet
/usr/ports/devel/py-apipkg
/usr/ports/devel/py-pytest-forked
/usr/ports/devel/libbson
/usr/ports/converters/fribidi
/usr/ports/graphics/librsvg2-rust
/usr/ports/lang/rust
/usr/ports/lang/vala
/usr/ports/devel/gettext-runtime
/usr/ports/devel/glib20
/usr/ports/devel/gettext-tools
/usr/ports/devel/libtextstyle
/usr/ports/devel/gobject-introspection
/usr/ports/graphics/cairo
/usr/ports/x11/pixman
/usr/ports/graphics/mesa-libs
/usr/ports/graphics/wayland-protocols
/usr/ports/graphics/wayland
/usr/ports/devel/libepoll-shim
/usr/ports/textproc/py-mako
/usr/ports/www/py-beaker
/usr/ports/devel/llvm10
/usr/ports/x11/libXdamage
/usr/ports/x11/libxshmfence
/usr/ports/x11/libXxf86vm
/usr/ports/graphics/libdrm
/usr/ports/devel/libpciaccess
/usr/ports/misc/pciids
/usr/ports/print/harfbuzz
/usr/ports/textproc/gtk-doc
/usr/ports/textproc/itstool
/usr/ports/textproc/py-libxml2
/usr/ports/textproc/yelp-tools
/usr/ports/textproc/yelp-xsl
/usr/ports/graphics/graphite2
/usr/ports/print/py-fonttools3
/usr/ports/devel/py-fs2
/usr/ports/devel/py-appdirs
/usr/ports/graphics/gdk-pixbuf2
/usr/ports/misc/shared-mime-info
/usr/ports/graphics/jasper
/usr/ports/graphics/jpeg-turbo
/usr/ports/devel/nasm
/usr/ports/graphics/libGLU
/usr/ports/graphics/freeglut
/usr/ports/graphics/tiff
/usr/ports/graphics/jbigkit
/usr/ports/x11-toolkits/pango
/usr/ports/x11-fonts/xorg-fonts-truetype
/usr/ports/x11-fonts/font-bh-ttf
/usr/ports/x11-fonts/bdftopcf
/usr/ports/x11-fonts/font-misc-meltho
/usr/ports/x11-fonts/font-misc-ethiopic
/usr/ports/x11-fonts/encodings
/usr/ports/x11-fonts/font-util

In order to use that with poudriere, I will need to remove the /usr/ports/ portion which I can do fairly easily in vi.  Once in vi, I type :%s/\/usr\/ports\///g which very neatly and efficiently removes the text, then I save the file by simply typing ZZ.  Ordinarily I would take the extra step to organize those port origins alphabetically and remove duplicates, but poudriere will do this for me.  One thing I need to be sure to do, is add x11-wm/fvwm3 to this list or it will not get built with all of its indirect dependencies.  This file as is should suffice for my present needs, and I do not expect to ever need to edit it or doublecheck anything.  Let's tell poudriere to get to work.  

portsup ; poudriere bulk -f `p-keg-deblack fvwm3-and-dependents` -j 13amd64

I can only hope that the list I made had included a number of things I would not need.  The poudriere build finished surprisingly fast, considering I told it to process seventy port origins.  The tail end of the output tells the majority of the story.

[00:12:57] Creating pkg repository
Creating repository in /tmp/packages: 100%
Packing files for repository: 100%
[00:18:46] Committing packages to repository: /usr/local/poudriere/data/packages/13amd64-default/.real_1620639651 via .latest symlink
[00:18:46] Removing old packages
[00:18:46] Built ports: textproc/py-mako textproc/py-recommonmark devel/py-atomicwrites devel/py-wcwidth devel/py-incremental devel/py-py devel/py-greenlet devel/py-argh net/py-eventlet devel/py-pytest devel/py-appdirs devel/py-pyasn1 devel/py-apipkg textproc/py-towncrier devel/py-pathtools math/cblas textproc/py-sphinx_rtd_theme devel/py-sortedcontainers devel/py-pytest-forked devel/py-fs2 devel/py-pyasn1-modules sysutils/py-filelock sysutils/py-execnet textproc/py-sphinx-inline-tabs devel/py-coverage devel/py-freezegun textproc/py-furo devel/py-watchdog security/py-trustme devel/py-pytest-rerunfailures security/py-service_identity devel/py-pytest-runner devel/py-pytest-mock devel/py-virtualenv devel/py-scripttest devel/py-mock devel/py-genty devel/py-wheel devel/py-tox devel/py-pytest-xdist devel/py-invoke devel/py-pympler devel/py-zope.interface devel/py-typed-ast devel/py-pytest-timeout devel/git devel/py-csv23 devel/py-pretend www/py-werkzeug sysutils/coreutils devel/py-pytest-cov devel/libbson devel/mercurial devel/py-flaky devel/py-pytest-freezegun print/py-fonttools3 security/py-cryptography-vectors
[00:18:46] Skipped ports: databases/db5 devel/apr1 devel/py-hypothesis devel/subversion graphics/librsvg2-rust java/openjdk7 math/py-numpy www/serf
[00:18:46] Ignored ports: java/bootstrap-openjdk6 math/suitesparse security/gnupg lang/rust textproc/rubygem-asciidoctor
[13amd64-default] [2021-05-10_04h22m05s] [committing:] Queued: 70 Built: 57 Failed: 0  Skipped: 8  Ignored: 5  Tobuild: 0   Time: 00:18:43
[00:18:46] Logs: /usr/local/poudriere/data/logs/bulk/13amd64-default/2021-05-10_04h22m05s
[00:18:46] Cleaning up
13amd64-default: removed
13amd64-default-n: removed
[00:18:46] Unmounting file systems

All that is left for the moment is to suffer the consequences of switching from one to the next.  I will have to deinstall FVWM2 in order to install FVWM3, and this should be handled fairly automatically by pkg when I tell it to install FVWM3, as it very obviously conflicts with FVWM2.

Interim patches

Patches should be interim fixes only.  How can FreeBSD ever be a recognized full member of the UNIX world if it always hides in the shadows, repairing for itself the linuxisms or other broken upstream code instead of communicating?  Even without making our presence known, telling upstream of our difficulties due to our distinct methods and organization, we can use the same mechanisms which upstream uses to adjust our build without need of patches.  One example is cmake, it is possible to discover the options provided by upstream to modify the build in various ways, to provide paths for dependencies, to enable or disable options.  We force the issue by reminding upstream that we are a consumer and by them providing flexibility which we can use to adapt their build without patches, or by their inclusion of our patches, if those developers listen and are open to such changes. 

Aside from my personal distaste for patches because of what I just mentioned, I also strongly favor our own options framework within the ports system to expose all or most build options.  I am okay with our public FreeBSD repo providing packages which are built using the most universally compatible defaults and among them the most used options as defaults.  However, we should not remove choice from our users.  There may be reasons to build with bundled software even if it may not be the best choice generally.  There are sometimes incompatibilities between ports which if installed together conflict due to dependencies in unique ways.  Choosing the less pleasant or potentially dangerous bundled software dependency can be the work-around in that situation. 

FreeBSD should have within its ports system, as many of the non-bundled versions of any necessary dependencies as possible, but they and all the other ports should also be able to be configured in ways that conflicts do not force the need of any bundled dependency.  Maintaining ports may be a bit of effort and adding additional options exposure for their users may increase the work involved, but it should not be the reason to avoid it.  We cannot know for certain that any group of ports must conflict among themselves or their dependencies if we limit build options.  Beyond the flexibility which may be offered by exposing more options, this exploration and investigation may determine that build options which upstream provides might not affect the actual build except to force dependency attachments.  We need to take care that minimal builds can be configured, that dependencies are known and our own dependency system handles them exclusively or in concert with those caused by any upstream build option. 

We have a rather extensive make system for our ports which is reasonably documented.  This collection of shortcuts in /usr/ports/Mk helps streamline many things, formalizes standards in a sort of macro form.  When and where it is possible it should be a choice for ports users whether to suffer the bulk of a dependency collection or be able to limit them.  Simply because KDE or GNOME or any other desktop provides a rather tightly integrated group of desktop environment with applications does not necessarily mean that it all must be installed in bulk.  If it is possible to pick and choose constituent parts, such as kate exclusive of KDE or some other utility exclusive of GNOME, this should be made as a separate port or port flavor.  For many possibilities we already have much of the mechanisms to handle situations or desires like this but for simplicity or assumed default user choices we might not provide them.  Any META port should not simply be a way for dependencies to be tied together for a one-step port install, especially something like KDE or Lumina, but also should provide options which permit the selection among those individual meta parts. 

We recently extricated base from GPL code, this is a success long in coming but it also truly should not have ever been a necessity, the inclusion not the removal.  Why do we not have more BSD licensed ports?  Why do we wait for any various thing to be developed in or for Linux distros and then we adopt it as a port, not as upstream provider but as a consumer depending upon the whims of developers which are not required to ever acknowledge us?  We can do better.  We are not devoid of creativity or skill or developers who could accomplish the same things for FreeBSD or any other BSD as those coders do for the Linux consumers.  What is our limitation?  Yes, FreeBSD is slow to change and does not chase after the most recent shiny, but can we develop a new shiny object?  It does not need to be a part of base and must not be widely adopted in order to be useful.  Perhaps we need a focus on FreeBSD innovation, to point out and point at those new bits of code, those new applications we develop on FreeBSD as upstream, and not simply give up to hand it over to those who would enjoy maintaining it and improving it as an awesome GPL licenced hit. 

Whether avoiding patches or creating new code, we in our BSD world need to make ourselves known.  We must communicate.  We must not simply be silent consumers feeding from the Linux engine.  We should be recognized, we should be present on operating system statistics distinct from Linux.  We can assist in maintaining the FreeBSD specific parts of any application that chooses to include us as a unique consumer.  We will never be supported if we hide in the shadows, pretending to be Windows or Linux because any mechanisms fail us when we claim our actual operating system designation.  It always begins as feedback to the developers, or resellers, providers; or we can remain a subsidiary of Linux development as a sort of leech on their continued successes.