[Talk] Re: [SAGE-AU] SUMMARY Package building software]
Steve Jenkin
sjenkin at pcug.org.au
Wed Oct 9 18:40:54 EST 2002
[A copy for those AUUG'ers out there :-)]
Many thanks to all those who replied. Credits listed below, then
summary, then original post...
No replies were received for HP-UX. Here are some old links I already
had, no idea of their current state/usefulness.
http://www.yacc.com.au/hp.html - YACC's HP-UX Resource List
http://hpux.ee.ualberta.ca/ - Software Porting & Archive Centre for
HP-UX
No replies for any of the other Sys V.2 derivaties, SCO or FSF/Tru64.
The closest thing to what I wanted was 'pkgsrc' [from NetBSD] that can
package for Solaris & others, besides NetBSD.
Steve Landers, as always, had a very interesting & provocative
viewpoint.
For applications, developers should just be delivering a _single_ file.
In Tcl/Tk there is a module that allows a local 'loopback' mount of a
file [the distribution], combine this with a 'stub' Tcl executable & you
have a very powerful way to deliver complete applications without
suffering many of the usual problems... Steve even has a way to
distribute a single CD containing both Mac & Windows and it 'Just Works'
(tm?)
The technique is portable to other [scripting] environments, not looked
to see it has been done.
I don't see this technique as generally applicable to the 'systems'
space where most of us play...
Hope this is useful.
SteveJ Wed 9-Oct-2002
==================================
Ben Elliston - autoconf/automake/libtool
Brad Marshall - Debian (.deb files)
Edwin Groothuis - FreeBSD 'ports'
grant beattie - NetBSD & 'pkgsrc'
Gregory Bond - FreeBSD 'ports'
Jason Thomas - Debian
Lee Sanders - Win (.MSI)
Paul Armstrong - Linux variants
Peter Nixon - Where to load a page...
Rob Kearey - Red Hat & rpm's
Scott Howard - doco on Solaris Packaging
Joe SHEVLAND - FreeBSD 'ports'
Steve Landers - Tcl/Tk + MacOS (.app file trees)
Zebee Johnstone - rpm
==================================
Ben Elliston
Autoconf isn't the package for packaging. If anything, it would be
Automake. You might want to check the Automake mailing list archives.
As it happens, Tom Tromey and I are working on a new tool to eliminate
autoconf/automake and libtool.
==================================
Brad Marshall
Debian uses .deb as the packaging format. Useful links are:-
http://www.debian.org/doc/maint-guide/ for the New Maintainers Guide,
http://www.debian.org/doc/developers-reference/ for the Developers
Reference, and http://www.debian.org/devel/ for general developer
related stuff.
==================================
Edwin Groothuis
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/
[building using ports] Was a piece of cake. For example, have a look at
the Makefile in
http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/dhcpdump/
The most difficult part of making a FreeBSD port is the first port you
make.
All looks new, all looks difficult etc. But once you've completed your
first you will never find it difficult again :-)
Oh euh, if you're doing this for a company, I would like to offer my
skills in FreeBSD porting: http://k7.mavetju/unix/freebsd.php
Enough experience ;-)
[[And a good demonstration]]
This is only for the port, which is used to make the package. If you
have read the ULRs you know the difference between ports and packages.
The makefile tells where to find the port (master_sites) and the name of
the tarball (portname + version + extension which
is defaulted to tar.gz). It has the list of man-pages in it (so they
will be compressed and stored as cat-files too)
A build of the port would go like this:
[/usr/ports/net/dhcpdump] root at k7>make
>> dhcpdump-1.4.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
>> Attempting to fetch from http://www.mavetju.org/download/.
58012 bytes transferred in 21.2 seconds (2.67 kBps)
===> Extracting for dhcpdump-1.4
>> Checksum OK for dhcpdump-1.4.tar.gz.
===> Patching for dhcpdump-1.4
===> Configuring for dhcpdump-1.4
configure: WARNING: you should use --build, --host, --target
checking for i386-portbld-freebsd4.5-gcc... cc
checking for C compiler default output... a.out
[...]
config.status: creating Makefile
config.status: creating config.h
===> Building for dhcpdump-1.4
cd . && CONFIG_FILES= CONFIG_HEADERS=config.h /bin/sh ./config.status
config.status: creating config.h
[...]
If there are FreeBSD specific patches (for example the name of
gtk-config which is gtk12-config under FreeBSD), they will be done at
the 2nd ===>.
[/usr/ports/net/dhcpdump] root at k7>make install
===> Installing for dhcpdump-1.4
/bin/sh ./mkinstalldirs /usr/local/bin
install -c -s -o root -g wheel -m 555 dhcpdump /usr/local/bin/dhcpdump
/bin/sh ./mkinstalldirs /usr/local/man/man1
install -c -o root -g wheel -m 444 ./dhcpdump.1
/usr/local/man/man1/dhcpdump.1
===> Generating temporary packing list
===> Compressing manual pages for dhcpdump-1.4
===> Registering installation for dhcpdump-1.4
And then:
[/usr/ports/net/dhcpdump] root at k7>make package
===> Building package for dhcpdump-1.4
Creating package /usr/ports/net/dhcpdump/dhcpdump-1.4.tgz
Registering depends:.
Creating gzip'd tar ball in '/usr/ports/net/dhcpdump/dhcpdump-1.4.tgz'
dhcpdump-1.4.tgz is now a FreeBSD package.
If there are any other things the program would rely on (for example,
gtk12) you would have mentioned it in the makefile and it would be noted
in the package. When installing the package it will check if gtk12 is
there already, if not it will install it first.
[/usr/ports/net/dhcpdump] root at k7>pkg_delete dhcpdump-1.4
[/usr/ports/net/dhcpdump] root at k7>pkg_version -vs dhcpdump-1.4
pkg_info: can't find package `*dhcpdump-1.4*' installed or in a file!
[/usr/ports/net/dhcpdump] root at k7>pkg_add dhcpdump-1.4.tgz
[/usr/ports/net/dhcpdump] root at k7>pkg_version -vs dhcpdump-1.4
dhcpdump-1.4 =
voila!
==================================
grant beattie
NetBSD's pkgsrc currently support NetBSD, Linux, Solaris and Darwin,
with HP/UX and other support in progress.
I use it regularly on NetBSD and Solaris, it is far superior to the
Solaris native package system, and it WORKS.
URL: http://www.netbsd.org/Documentation/software/packages.html
and further information on using pkgsrc on non-NetBSD systems:
http://www.netbsd.org/zoularis/
It also has support for building native Solaris style binary packages
which can then be installed with the usual pkgadd tools.
pkgsrc itself has support for building binary packages, as well as
including a digital signature (from gpg).
Dependancies are automatically handled, which is great when you have a
package with a lot of dependancies (mmm, mozilla, or mplayer for
example) :-)
Its primary development platform is obviously NetBSD. It was originally
based on the FreeBSD Ports collection, but has since been significantly
expanded and multi-platform support is growing quickly.
It can also be used to install binary distributed software, such as
Netscape 7 for Linux. It is certainly good to know that everything in
/usr/pkg (or whatever LOCALBASE you use) is registered as belonging to a
package.
==================================
Gregory Bond
FreeBSD (And I think NetBSD and OpenBSD) use a "ports" structure to
build stuff from source, with the option of building a binary "package".
See
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html
for an overview.
Have I built a port for something not already in the ports tree? Sure,
several.
It can take ages if you are porting a large and difficult program, but
that is true no matter how you package up the results.
==================================
Jason Thomas
debian has dpkg (which is the same thing as the rpm command - with
different options) to install packages. apt-get is used to automate
downloading and installing/updating packages from debian ftp/http/rsync
servers.
there is a tool called 'alien' which will convert from debs to rpms to
tarballs to unpacked debs/rpms/etc. This is available on redhat and
debian, i think.
http://packages.debian.org/unstable/base/dpkg.html - not really helpful
http://www.advogato.org/proj/dpkg/ - this one is old
http://www.kitenet.net/programs/alien/
[and attached 2 man pages, not included here...]
==================================
Lee Sanders
For windows your package format is MSI. Many different ones, I would
recommend
"Wise for Windows 4" or "Installshield Admin Studio"
We use Wise for Windows and have all the software used in the university
environment packaged. Takes us less than 10 mins to install/setup the
software for a machine.
==================================
Paul Armstrong
Debian uses deb packages.
Apt-get is simply a frontend for package management.
dpkg is the main suite of programs for working with (including building)
packages.
Package system works wonderfully. Dependencies are checked fully on
install and the package supplying the required item is listed.
> Are there any other Linux package variants?
Slackware uses tarballs.
Gentoo uses a FreeBSD like build system.
FreeBSD uses tarballs with added information (a bit like Solaris).
The main way of adding non-system software is through the ports system.
This allows you to build the software from source and it installs it as
a registered package so you can modify it as requried.
The core operating system is not packaged at all. It is built from
source from which you can select not to build certain sections via
make.conf.
==================================
Peter Nixon
http://www.cotse.com
==================================
Rob Kearey
[Building rpms] Fairly straightforward, really. You can just use a
skeleton spec file and flesh it out. It's generally just a matter of
making a buildroot, autoconfig with patches, build and go, just as an
example.
Also depends on what you mean by helper scripts. rpm support %pre and
%post directives for scripts to be run before and after installation.
[On problems making packages] Well, not quite. You still need to do a
filelist, &c, but you can generally do that via a src.rpm. It's
important to keep in mind the difference between a src.rpm and the
binary rpms it generates. For example:
foo-1.2.src.rpm
rpmbuild --rebuild foo-1.2.src.rpm
might generate
foo-1.2.i386.rpm
foo-1.2-devel.i386.rpm
foo-utils-1.2.i386.rpm
Typically, for a src.rpm, you have a tarball, and a list of patches. rpm
will unpack the source, apply patches, do an autoconfig (for example),
apply post-patches if needed, build, make md5sums, and package up
according to the spec file. rpm does however have helper apps to make
buildroots, that kind of thing.
Any kind of packaging soon becomes a black art, really. rpm is very good
at it, though :)
http://www.rpm.org.
Note that rpm has been revamped substantially for rpm 4.1.
--
Rob Kearey Website: http://apac.redhat.com
Red Hat Asia-Pacific Legal: http://apac.redhat.com/disclaimer
+61 7 3872 4803 Stuff: http://people.redhat.com/rkearey
==================================
Scott Howard
Not exactly what you're looking for, but..
http://www.docbert.org/Solaris/Pkg/
I really need to html'ize it one day...
==================================
Joe SHEVLAND
I'm sure someone will go into it in more detail, but in brief FreeBSD
uses the Ports system to distribute application packages, which can have
dependancies on other packages. The ports system will pull down the
relevant source packages from a master site (with configurable
alternatives), rebuild the software, branch off and build other
dependancies and return to the original build, and finally register the
package in a package database (and potentially a lot more features that
I don't use, can't recall at the moment, or don't understand ;)
http://www.freebsd.org/ports/
is a good official starting point for further information on the system.
But no, I haven't ever rolled my own port, ...
==================================
Steve Landers
I don't know if this is exactly what you are looking for, but you might
find http://www.digital-smarties.com/Tcl2002/tclkit.pdf interesting. I
presented this paper 2 weeks ago at the 9th Annual Tcl/Tk conference in
Vancouver.
Re other OS's doing packages - MacOS X has a really neat facility
whereby an entire directory tree becomes an application. Sort of like a
package, except that you don't need to "install" just copy your disk.
>From memory they are called .app bundles or something similar.
Autoconf is, IMNSHO, part of the problem not part of the solution. Read
my paper and you'll see why.
But, in summary, why should application developers care about all that
gumph - it should be hidden.
>Is the problem a 30-yo paradigm of 'C' programs and re-inventing the wheel [vs building on what has gone before]??
I suspect the problem is system administrators thinking they are
software engineers or computing scientists ;-)
I would argue the set of skills needed to be a good system admin is
almost tangential to the set of skills needed to be a good computing
scientist. RPM (et al) is a system admin solution to a problem that
perhaps should be avoided altogether.
==================================
Zebee Johnstone
I use redhat to package stuff.
Basically you need a version of rpm on the build machine and the machine
to install on.
You tar up the source, which can be either something to be configged and
compiled or else a bunch of files. You write a SPEC file, which has pre
and post install shellscript ability, including the ability to run
scripts that are in your source. This SPEC file tells the rpm
program how to get the files to package, and what to do with the files
when installed.
You give the SPEC file config and install commands, and a list of files
that will be in the final RPM. when you create the RPM it performs what
config, compile, and install commands you have given it, then it gets
the files you tell it to package, and packages them.
you can have several sub-packages, I have 4 colocated servers that
require the same apache virtual sites, but have different IP addresses
and mail requirements and so on, but the same file suffices for
logrotation and other scripts. So each virtual server has one SPEC
file, with some files in the source the same and some individual ones
for each colo. The SPEC file has a section for each colo, that runs the
colo-specific scripts, and packages the files for each colo. It
produces 4 different RPMs, but I only have to change things in one file
and one source tarball.
I find it useful - decent version control, easy central configuration
that can deal with some files on each machine being the same as other
machines, and some files are different, plus it can do anything a
shellscript can.
see http://www.rpm.org it has a documentation link that has good
explanations.
==================================
[[Another note from me]]
I was going to write a little paper on making packages AND I thought
this would be a perfect thing to add to autoconf - adding targets to the
makefile that create proto-packages, build & test packages.
==================================
Original Post:
==================================
>
> I'm looking for software to build 'packages' on different Operating
> Systems - good/bad comments on them also solicited.
> Replies to me & I will summarise within a week or so - could you please
> indicate in your replies if I CANNOT include all/part of the reply in
> the summary. I expect to cut/paste the whole of received replies.
> [And I'd like to make a short 'white paper' from this as well. Any
> ideas on where it could be loaded?]
>
> - and feel free to share relevant experiences with the whole list :-)
>
> Linux:
> ======
> Redhat et al use 'rpm' format & the rpm command can build packages.
> I've never tried to build a package in RPM and don't know if it needs
> 'helper' scripts or not.
>
> Debian - haven't got a clue ;-) Know there is something like 'appt-get'
> & '.deb' files,
>
> Are there any other Linux package variants?
>
> NetBSD/FreeBSD/OpenBSD:
> ======================
> Don't know anything about them. I'm sure the Wasabi crew can (&will)
> give me a good rundown :-) TIA
>
> AIX:
> ====
> <A HREF="http://www.bullfreeware.com/">Bull's Large Freeware and Shareware Archive for AIX</A>
> Have used the package builder on this site - works fine. Simple, easy -
> highly recommended.
>
> Solaris:
> =======
> Have used a 'home-brew' system from IP Australia that built on the
> standard Solaris commands. Yes, you can hand-build Solaris packages,
> BUT some helper scripts [that auto generate the directory structures,
> config files and other proto-files] it really becomes a breeze.
> Anyone seen a public domain Solaris 'package builder'?
>
> HP-UX:
> ======
> Have a friend at DFAT who builds HP-UX packages. Don't know how hard it
> was, or what sort of 'helper' scripts he needed.
>
> Other Unixes:
> ============
> SCO, Digital Tru64 (FSF), SysV.2 & V.4 variants..
>
> Other O/S:
> =========
> Do other O/S even 'do' packages??
> NT has 'Service Packs' - but these seem to be the equivalent to
> 'tarballs' - no pkglist, remove/rollback or central inventory. I've
> been told that SMS has something like packages, but I've never seen it
> in action or heard more.
>
> Other OSes?? MVS, VMS, do we care??
>
> TIA
> sj
> --
> --------
> Steve Jenkin, Unix Sys Admin
> PO Box 48, Kippax, ACT 2615
> 0412 786 915
>
> ----------
> The SAGE-AU mailing list is a member-only service. Postings to this list are
> made by individual members, and do not necessarily reflect SAGE-AU policy or
> position. This article may not be reproduced or quoted beyond this forum
> without written permission of all contributing authors. Further information
> can be found at http://www.sage-au.org.au/maillist.html
--
--------
Steve Jenkin, Unix Sys Admin
PO Box 48, Kippax, ACT 2615
0412 786 915
----------
The SAGE-AU mailing list is a member-only service. Postings to this
list are
made by individual members, and do not necessarily reflect SAGE-AU
policy or
position. This article may not be reproduced or quoted beyond this
forum
without written permission of all contributing authors. Further
information
can be found at http://www.sage-au.org.au/maillist.html
More information about the Talk
mailing list