[lug] February 14th talk?

[D. Stimits]

Tom Tromey wrote:
> 
> >>>>> ">" == D Stimits <stimits at idcomm.com> writes:
> 
> >> More food for thought on packaging: If I were to spend some of my
> >> idle unemployment time making a package tool, it would be a moduler
> >> OO design, with "plugins" for various file formats to output. I
> >> would be interested in knowing if the various package speakers see
> >> a common theme of describing input packages, the purpose being
> >> something like an abstract package description language that could
> >> be used in an OO program to produce *any* output format.
> 
> I've looked at doing this before.  I stopped since there didn't seem
> to be an obvious user base.  Every vendor has already solved the
> packaging problem to their own satisfaction.

I would like a tool that integrates all the other tools. Those
distributors that have solved their own distro problems create
differences that are hard to deal with if you run from a different
platform. The tool I am thinking of would NOT be a packaging tool, but
instead a GOOD front end that has a meta-packaging language which could
be adapted via plugins to package in each of these different distributor
formats, using their tools. Think of it as a way to seamlessly integrate
completely different tools using a single description. A module would be
used that has enough intelligence to know what to do for a given format,
e.g., it might have a module that defines Mandrake rpm formats and
Redhat, as well as Debian, and "do the right thing" using their
particular tools. If names or locations had to be relocated, it would
have an ability to do so, or at least make a suggestion, and save the
details of alterations for each platform. I would not want to write such
a tool for any other platform than Linux, but it would probably be easy
to take a modular tool like this and have it work elsewhere. Think of it
as a convenient and easy-to-use (the hard part) preprocessor to
packaging tools.

D. Stimits, stimits at idcomm.com

> 
> In any case, my conclusion was that most of the packaging systems (and
> certainly the Big 2 Linux systems -- I was also looking at Solaris,
> HP, Irix) use pretty much the same info; they just represent it
> differently.  The real problem with a generic packager is not in the
> formatting, though, but in deciding what parts of a source package
> should go into which binary package.  Every distribution seems to have
> its own policies regarding package naming, splitting packages, etc.
> 
> In any case, someone else has started work along these lines.  They
> have patches to automake which give it package targets:
> 
>     http://www.gyve.org/~jet/autopack/
> 
> I haven't (yet) looked at this.  This web page (if you can read it --
> I find their color selection terrible) has links to a couple other
> similar projects.  This one might be interesting to you:
> 
>     http://psychomix.dhs.org/projects/buildpkg/
> 
> Tom
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug