Joseph K. Myers
Thursday, October 23, 2003
Compiling/porting the software generally has a few steps.
The last item is very important. I am disappointed with tools like Fink which disobey it. The main thing is that every software should exist in one copy on your machine. You might not know how much pain it can cause if there are ever more than one installation of the same thing (by same I do not mean the same version)
It seems like you can just make a decision to install something like perl 5.8.1 alongside perl 5.6, by putting a new one in /bin/perl, and one in /usr/bin/perl. It is not so simple. What do you do, dear, when someone wants Net::POP3 installed?
Essentially, there is no meaning to software when it is copied in multiple variations over one system. (The exception being documents, which in some license agreements also constitute software. I wonder if they should make such redefinitions illegal--i.e., that software cannot be taken for other than machine instructions--because supposing that a license agreement could be defining software as your soul, then "destroying all copies of this software, if you choose to abandon the agreement," would mean destroying your soul. Hmm, yet so far license-writers have all of the rights...)
In particular, I find it very convenient to use the files in /usr/share/libtool within compilation, to use older distributions unmodified (unpatched) except for newer configuration and build components (weapons!).
Just as an example, in Amaya I will do
cp /usr/share/libtool/config.{guess,sub} Amaya
cp /usr/share/libtool/ltmain.sh libwww/config
before I configure.
The harder part is when there are along-the-way steps to be taken. Just to admit it, I don't know how to patch the Amaya source code so that it will compile from beginning to end. Part of the files which need changing, will need their changing later on, because they are only created at some point after an invocation of make (like HAVE_APPKIT_APPKIT_H, which is in libwww/wwwconf.h, a file that is created later on).
The main problem of course, is that foolish people make bad assumptions in their configure scripts.
11-4-03.
The main thing is I want my porting mechanism to be simple, so that in fact the porter parts are installed, so that an installer can be any kind of mechanism, with or without "the porter" as an entity.
An example could be as simple as
#!/bin/sh d=wget.d src=http://www.myersdaily.org/joseph/notes/software/wget.tar.gz f=wget.tar.gz a=/usr/local/bin # quote "compile" mkdir $d cd $d curl -O $src tar -xzf $f # install cp wget $a
It's actually kind of very cool that Unix commands
don't return string/output values, like you would think
that mkdir could return the value of $d, so
that it would be easier to say
cd (mkdir($d)), as you might if it were in another language.
But efficient programming loves logical control with numbers
not `core dumps~'. I'm glad they had to do it that way then,
because its improvement is still lasting until now.
A better example is add-account and add-group needed by qmail, or 'update-config-guess', etc.
Prerequisites could automatically be removed from listings, if one of the other prequisites in turn requires the same prerequisite already. I.e., "graphic-lib" might require "jpeg," so "Imgapp" that lists "graphic-lib, jpeg" could automatically (safely) store the prerequisite as "graphic-lib."
There would never be versions of the same thing. jpeg should not be listed as jpeg-1, jpeg-2, for instance. If a separate thing is needed, it is separately named, not as another version. Whenver other things are "unsupported" by a new version, really those other things have just dropped off of the line themselves, rather than the other way around. They have to be dropped as a matter of priority. (This safely argues for the fact that change is not good, sometimes. If one line of code needs to be updated in 'jpeg', then it should not be changed as a matter of breaking a five-year-later program that uses it, because the five-year-later program isn't going to be able to change. However, the worst case of all is keeping two 'jpegs' for this scenario. That, at all faces, is evil.)
As little information as possible would be kept, inside of a CDB file, read with C programs.
Now the idea is that 2,000 things will eventually be in the collection, but the love and care must come first to the design, or it'll be just as horrible as fink has become.
And of course, in porting software, we know that the gold standard is not. The version 1.0 is not the ultimate goal of our port, that we should bend and yield everything far enough to obtain. We move it in the right direction, so that the port collection is the stable island, not a moving target like some other things.
It's good to follow good practices, but not to make the good practices become bad for other things than themselves.
2-28-04. Fixed "prequisites" to "prerequisites" in two places. (It was a typing mistake, because the first time it was spelled correctly.)