Mailing List Archive

Support open source code!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No Subject



--------------------------------------------------------
tlug note from "Stephen J. Turnbull" <turnbull@example.com>
--------------------------------------------------------
>>>>> "Thomas" == =?iso-8859-1?Q?Thomas B=E4tzler?= <iso-8859-1> writes:

By the way, anybody have any suggestions for handling quoted-printable 
headers in Emacs RMail, MH-E, Supercite, and MH's scan?  I'm seeing
more and more of them these days....

    Thomas> tlug note from joem <root@example.com>

    Joe> If I build Perl (for instance) I get 16 compiled binaries in my
    Joe> /usr/local/bin subdirectory.  What I've been doing is renaming
    Joe> the binaries to include the version numbers (ie perl -->
    Joe> perl5.003) and using symbolic links back to the executable name
    Joe> in the same subdirectory.

It's not clear to me what your question is.  Are you keeping multiple
versions around?  If so, to what end?

    Joe> The problem is that with multiple versions of packages and all
    Joe> the symbolic links, I end up with a whole lot of files in one
    Joe> subdirectory, which becomes confusing.

"find <path> -type l '<glob pattern>'" might help with this.

    Thomas> [...]
    Joe> There may be other ways to handle this as well.  Any
    Joe> suggestions about which way is best?

    Thomas> Well, the easiest way out would be to use a distribution
    Thomas> that takes care of the version management for you,
    Thomas> i.e. Debian. Doing that would mean that you don't get to
    Thomas> spend so much time compiling and installing bleeding edge
    Thomas> software :-)

Exactly.

    Thomas> A rather neat thing would be to rewrite the install
    Thomas> package used in most of the GNU software, so that a make
    Thomas> install would rather create symlinks to your compiled
    Thomas> binaries instead of copying the files. But then you'd
    Thomas> still be stuck with sorting out the inter-package
    Thomas> dependencies...

Well, we already have RPM and dpkg.  That's what they're for, isn't
it?  So we should rather make RPMs.

What I do with software that I beta test, and other software where I
keep multiple versions, is the following.

(1) Split the package into architecture-dependent and architecture-
    independent portions.
(2) Architecture-dependent portions go into /usr/local/lib/<pkg>/<ver>
    and the rest into /usr/local/share/<pkg>/<ver>? (things like fonts
    and dictionaries that don't change very often or have standardized
    formats don't get separated by version, things like initialization
    files do).  This kind of thing of course only works where the
    software supports path searching.  Under these top-level
    directories go .../bin, .../etc, and so on as necessary.
(3) The stable version gets symlinked to /usr/local/bin/<prog>.  Test
    or special-purpose versions I do a
    PATH=/usr/local/lib/<pkg>/<ver>/bin:$PATH in the shell where I'm
    testing.  For things that I do a lot of this, I have scripts that
    do this for me in a new window.

But most software I just install the new software over the old ones,
and every so often I clean out obsoleted binaries.

Check out the Linux File System Standard for some theory on this kind
of thing (although FSSTND is mostly concerned with the difference
between `bin' and `sbin'), the systems that Emacs and GCC use for
handling architecture dependencies, and (much more primitive)
Ghostscript, for examples.  For path searching taking to an insane
extreme (but necessary in the application), check out Karl Berry's
kpathsea library (comes with "web" versions of TeX, and the "k"
versions of xdvi and dvips).

-- 
                            Stephen J. Turnbull
Institute of Policy and Planning Sciences                    Yaseppochi-Gumi
University of Tsukuba                      http://turnbull.sk.tsukuba.ac.jp/
Tel: +81 (298) 53-5091;  Fax: 55-3849              turnbull@example.com
-----------------------------------------------------------------
a word from the sponsor will appear below
-----------------------------------------------------------------
The TLUG mailing list is proudly sponsored by TWICS - Japan's First
Public-Access Internet System.  Now offering 20,000 yen/year flat
rate Internet access with no time charges.  Full line of corporate
Internet and intranet products are available.   info@example.com
Tel: 03-3351-5977   Fax: 03-3353-6096


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links