Re: Guidelines for multi-distro spec files?

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

 



Circa 2003-12-02 13:25:34 -0800 dixit Hal Wine:

: Thanks, much, Jim. That's a great starting point.

No worries.

: Can you give any guidance on how much "extra" time is needed to
: support spec files that work for multiple distributions?  I.e. are
: they significantly more "fragile" than single distribution RPM spec
: files?

Disclaimer: it's been a while since i did a lot of work in this area.
When i was more actively doing this, i was doing two sorts
of things:

  (1) Keeping certain software packages up to date that either did not
      accompany the system, accompanied the system but were not
      configured to my liking, or accompanied the system but were older
      versions.  For example, OpenSSL and OpenSSH.

  (2) Preparing RPM packages for a commercial software vendor (my
      employer) for installation on multiple versions of multiple
      distros.

That said, while multi-distro specfiles are more fragile than
single-distro specfiles, i found that it was significantly less work to
maintain one multi-distro (or even multiple versions of a single distro)
specfile than two or more single-distro specfiles.

Alternative methods of supporting multiple distros include:

  (a) Using a preprocessor (such as cpp, m4, or homegrown sed/awk/perl)
      to create multiple single-version specfiles from a template.  I
      did this sort of thing when i was maintaining prebuilt RPMs for
      the Window Maker window manager (www.windowmaker.org) back at the
      turn of the century.  Unfortunately, i'm unable to find any
      examples of that specfile template around on the net; it seems to
      have disappeared.  I'm sure i have it somewhere, but i'm not at
      that desk at the moment.

  (b) Using a different mechanism containing the logic for building and
      installing the software package, coupled with a simple specfile
      and 'rpmbuild -bb'.  The LSB (Linux Standard Base,
      www.linuxbase.org) uses this method for building its "application
      battery" containing sample LSB-conformant software packages.

You might also have a look at what the OpenPKG folks are doing
(www.openpkg.org).  They've put together an entire suite of useful
software packaged in a portable fashion for a number of different
operating environments.

Finally, You may wish to have a look at the following other examples of
more-or-less portable software package systems:

  - the NetBSD "pkgsrc" collection
    (www.netbsd.org/Documentation/software/packages.html)
  - the Encap package manager, 'epkg' (www.encap.org/epkg/)
  - D. J. Bernsteins '/package' web page (cr.yp.to/slashpackage.html)

Hope that helps.

-- 
jim knoble  |  jmknoble@xxxxxxxxx  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
 .....................................................................
 :"The methods now being used to merchandise the political candidate :
 : as though he were a deodorant positively guarantee the electorate :
 : against ever hearing the truth about anything."   --Aldous Huxley :
 :...................................................................:

Attachment: pgp00009.pgp
Description: PGP signature


[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux