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.