[csw-maintainers] GAR, alternatives, and general integration of GAR

Philip Brown phil at bolthole.com
Mon Apr 12 22:38:00 CEST 2010


On Mon, Apr 12, 2010 at 1:07 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Phil,

*wave*

> Am 12.04.2010 um 18:50 schrieb Philip Brown:
>>
>> So, I saw a recent mail, I think from Dagobert, about how to enable
>> "alternatives" use in GAR.
>
> This wiki-page?
>  <http://sourceforge.net/apps/trac/gar/wiki/Alternatives>

oops.. yes I think that was it.


>....
> And this is a *good thing* as the maintainers is not forced to
> understand every bit of it. If you are interested in something it
> is of course better to understand it, but there is rarely the need.
> The task of GAR is exactly hiding the ugly details like "how do
> I assemble a package with 32/64 bit with isaexec" by condensing it
> down to BUILD64=1.

Except of course, that we've had recent troubles of packages
inappropriately doing too much 64bit, and people not realizing how to
par that down :)

But in general, yes I think that's a good thing.
It's a nice, simple one line GAR thing.


> Take Texinfo-files: To properly put them at the right location, set
> the class for the texinfo-files, add the class in the correct order,
> all this is done *without any intervention* from the maintainer.

and this also I think is good. It doesnt require the maintainer to
particularly "learn gar".
Automatic, is good.


Unfortunately, it does not seem possible to make providing an
"alternatives" implementation in a package, "automatic".   or even
"simple".
That is what I am resisting here.

However,....  having thought about it some more, I think i've picked
up some missing pieces that you didnt explicitly say in your wiki
page, but may be true non the less.


You seem to be viewing it from a perspective of,
"I want to split up/recompile ONE software tarball, into multiple,
different-back-end packages".
Which IS actually somewhat complex, and I can see how that would
benefit from GAR assistance.

On the other hand, I am for some reason more focused on a view of
multiple maintainers, with their own package, and each compiles
something individually.
This may be unrealistic.

So, me going along with the idea of "Gar really does make this
easier".... would you please simplify your wiki page about it?

Right now, there are two, completely separate, examples. mostly
"code"(makefile), and not enough explaination.

MIght you move out the complicated automake stuff (or relegate it to a
"page 2" kind of thing, and then explain more what is going on with
the mutt exaple please?


More information about the maintainers mailing list