New news post
This commit is contained in:
Nathan Fisher
parent
d5be32d304
commit
fddfbf0293
|
|
@ -0,0 +1,84 @@
|
|||
+++
|
||||
title = "Packaging for 2021q2"
|
||||
date = 2021-02-26
|
||||
[taxonomies]
|
||||
tags = ["NonGNU","Packages","Pkgsrc","C Programming","POSIX"]
|
||||
+++
|
||||
I spent a good deal of the past couple weeks working on actually getting init up
|
||||
and running, preparing kernel configurations for multiple architectures, and
|
||||
learning about Das U-Boot in order to put up bootable images. Taking a little
|
||||
break from that the last few days, I am now once again working at building a set
|
||||
of packages using pkgsrc.<!-- more -->
|
||||
|
||||
Inevitably considering how many utilities have been replace in Hitch Hiker for
|
||||
either BSD versions or scratch implementations, I have been running into breakage
|
||||
in odd places. Most are relatively easy fixes. A few kept repeating in an
|
||||
infuriating manner...
|
||||
|
||||
GNU autotools is an attempt to make a framework that allows building software on
|
||||
multiple architectures and operating systems. I won't attempt to elaborate much
|
||||
on how it works, but in order to support as many different systems as possible
|
||||
the lowest common denominator is assumed when it comes to the infamous 'configure'
|
||||
shell script, meaning that it is supposed to be POSIX compliant and not use any
|
||||
extensions to the POSIX spec in relation to shell grammar. I'm mentioning this
|
||||
because a whole bunch of Gnome related packages use the same test for intltool in
|
||||
their configure sript. The gist of the test is this:
|
||||
```Bash
|
||||
intltool-update --version | head -1 | cut -f" " -d 3
|
||||
```
|
||||
I previously ran into this when compiling and testing Servo, the browser engine
|
||||
formerly sponsored by Mozilla written in Rust. I was pissed at the time, because
|
||||
it's such a simple thing. Basically, the POSIX spec only includes the -n option
|
||||
when describing the behavior of the head utility. And my version of head did not
|
||||
support the older syntax ```head -[num]``` as it is not possible to code that
|
||||
sort of thing by just using getopt. The BSD head actually parses and rewrites
|
||||
argv in order to support this. Not sure what GNU does but I'm sure it's a few
|
||||
hundred lines that shouldn't be necessary.
|
||||
|
||||
The fact that this is the same test, with exactly the same syntax and whitespace,
|
||||
is a dead giveaway that the package authors basically have just been copying and
|
||||
pasting the same code without ever reading or understanding it. It's also indicative
|
||||
of another thing I hate; passing --version to a utility should return a string of
|
||||
numbers, not multiple lines including a copyright statement and author credit.
|
||||
There should be no need for calling head to begin with.
|
||||
|
||||
Furthermore, checking for package versions is bad practice to begin with. Say I
|
||||
created a fully functional drop-in replacement for intltool. It does exactly what
|
||||
intltool does, it accepts the exact same input and gives identical output. If I
|
||||
then tried to build any of these packages that check for a specific version of
|
||||
intltool they would fail. Best practice is to check for capabilities, not version
|
||||
numbers.
|
||||
|
||||
To fix the issue I did what I had said previously that I didn't want to do; made
|
||||
the head utility in Hitch Hiker accept the non-conforming syntax. I also hacked
|
||||
our BSD originating **uname** utility while I was at it to accept the GNU -o
|
||||
option and just alias it to -s, as a few things had choked on that option.
|
||||
|
||||
### Creating a Hitch Hiker overlay for pkgsrc
|
||||
One of the changes that I have been tinkering with in the base system without
|
||||
success is the ability to build the other components of gcc beyond the C and C++
|
||||
compilers. I have had no luck building the Go, Fortran, Objective C or Objective
|
||||
C++ frontends with the sysroot build. So I tried to build the gcc10 version from
|
||||
pkgsrc, only to have the Go compiler fail at the last moment. Interestingly, I
|
||||
was able to build all of the components manually with zero issues. In looking at
|
||||
the Makefile in pkgsrc/lang/gcc10 I realized that there's quite a lot of
|
||||
conditionals to aid in building on different platforms and there are also quite a
|
||||
lot of options passed to configure beyond what I normally use. In short, for our
|
||||
limited purpose I thought that I could do better.
|
||||
|
||||
What I have created is a Hitch Hiker specific overlay for pkgsrc. Basically, the
|
||||
overlay gets extracted in the same location as pkgsrc and adds some Hitch Hiker
|
||||
specific packages, prefixed with hhl_ in their name. The hhl_gcc10 package is
|
||||
beautifully simple, builds in approximately 1/3 the time as the pkgsrc version
|
||||
(we skip the three stage bootstrap of gcc as we're compiling it with the same
|
||||
version from the base system) and builds the C, C++, Fortran, Go, Objective C and
|
||||
Objective C++ frontends. Additionally, the pkgsrc gcc10 package puts everything
|
||||
under a different prefix, /usr/pkg/gcc10, rather than /usr/pkg. I don't like
|
||||
adding extra prefixes in general, so I didn't follow suite with that practice.
|
||||
|
||||
I think this is actually a better solution in the long run than continually
|
||||
patching pkgsrc for things that fail to build on Hitch Hiker. If a package
|
||||
requires a specific change, I can create a new package that does build and it can
|
||||
be installed with the name of the original to satisfy dependencies while we try
|
||||
to get changes pushed upstream. In this way we can still have a fairly maintainable
|
||||
set of Hitch Hiker specific changes, as they will live in their own repo.
|
||||
Loading…
Reference in New Issue