Re: Package support (RPM, deb, pkg, kits, etc.)

[Michael Still]

On 12 Jan 2001, Tom Tromey wrote:

> I do think it would be useful.  However it seems that most package
> maintainers are not also the package developers.  And, most package
> maintainers only develop for a single platform.

I'm not sure this is true... I know for the software I write, I also
created the packages, and this seems to be the case for many of the people
floating around such places as sourceforge and freshmeat.

> Rusty> - As an end user who builds & installs software on my own
> Rusty> systems, I would rather build & install a package appropriate
> Rusty> to my system than "make install".
>
> That's interesting.  I don't hear that much!

Be reassured, most of the system admins I know do it this way...

> Anyway I think the big problem is sub-package breakdown.  Maybe this
> is solveable.  I'm willing to put patches into automake that help with
> `autopackage'.
>
> The automake-related idea I had was that installable objects would be
> marked by the sub-package they belong to.  Something like:
>
>     lib_LIBRARIES = libfoo.a
>     devel_header_HEADERS = foo/foo.h

Why don;t you just have some different primaries? Like, for instance:

rpm_PROGRAMS = foo
foo_SOURCES = foo.c wibble.c hamster.c

I guess this means if you want a DEB as well, then you would have:

deb_PROGRAMS = foo

Cheers,
Mikal

PS: Nice book, I might one day finish reading it if I can find the time...

-- 
Michael Still (address@hidden)
 - Panda PDF Generation Library 
(http://www.stillhq.com/cgi-bin/getpage?area=panda&page=index.htm)
 - PandaLex PDF Parsing Library 
(http://www.stillhq.com/cgi-bin/getpage?area=pandalex&page=index.htm)
 - PandaScript PDF Scripting Interface 
(http://www.stillhq.com/cgi-bin/getpage?area=pandascript&page=index.htm)
 - GPG Public Key at http://www.stillhq.com/mikal.asc and on pgp.net keyservers

"To read makes our speaking english good" -- Xander, Buffy the Vampire Slayer 
in "I Robot, You Jane"