I've done a great deal of this. The amount of extra time needed to
support a spec that works on multiple distros is quite large. It is mostly
testing effort, I believe. When problems are discovered, they are generally
fixed quickly, but the test matrix is large and complicated.
I agree with Jim that it is easiest to support a single spec file for all supported
distros. You can have a single SRPM that you use to build a binary RPM
on each supported distro, or you can build a single binary RPM that
works on each distro ("one size fits all"). If you do the latter, you'll probably
have to build on the distro with the oldest libraries, and hope that all the
rest are sufficiently backwards compatible to make it work.
Alternatively, you can explore making your app LSB compliant, and
require that supported platforms be LSB compliant.
http://www.opengroup.org/lsb/cert/cert_prodlist.tpl
One of the hardest parts is with init scripts. If your package doesn't
include a daemon that should start at boot-time, you're in luck. If you
do have a daemon, you'll have to write the init script in such a way
that it works on all distros. This means using both chkconfig comments
and INIT INFO comments. Also, in your %post
and %preun you'll have to do different things to register the init script
with the system. Do you use chkconfig, insserv, or /usr/lib/lsb/install_initd?
Here in particular your life will be easier if you can require that the platforms
you install on are LSB compliant. Then you only have to code for one way
of doing things.
http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/iniscrptact.html
http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/initscrcomconv.html
http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/initsrcinstrm.html
http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/iniscrptfunc.html
Even if you don't fully embrace LSB, you'll do well to follow the FHS and the LSB
package naming conventions. This means installing everything into
{/var,/etc}/opt/<package> or {/etc,/var}/opt/<provider> where <provider> or
<package> are registered with LANANA (www.lanana.org). Also, prefix your RPM
name with "<package>-" or "<provider>-" as well as your init scripts (which have
to go in /etc/init.d vs. /etc/opt/<package>). This way you will avoid the potential for
namespace collisions. Hint: LD_RUN_PATH (not to be confused with LD_LIBRARY_PATH)
can be very useful here. See 'man ld' for details.
For examples, you can look at these:
http://forge.novell.com/modules/xfmod/project/showfiles.php?group_id=1306&release_id=989#selected
Of particular interest might be the init scripts within the packages and the handling of init scripts
in %post and %preun. You'll have to pick a package that has a daemon to see those, such as apache,
tomcat, or samba.
Hope this helps. Feel free to ask if anything needs to be elaborated.
On Tuesday 02 December 2003 3:02 pm, Jim Knoble wrote:
> 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.
--
Bart Whiteley <bwhiteley@xxxxxxxxxx>
Novell, Inc., the leading provider of information solutions
http://www.novell.com/
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
