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

[Dagobert Michelsen]

Hi Phil,

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>

> But it brings up a side issue.
>
> I have noticed in times past, a flaw in debian.
> There has long been the framework of "debian helper", to help people
> build debian packages. It gets more and more complicated over time.
> And it has even gone through a few major re-workings, which were
> semi-incompatible with older versions.
>
> Like GAR, it was basically a layer on top of the "real" debian package
> interface.
>
> The problem is that people had to learn "debian helper", to use it,
> and learning it ended up being almost as complicated as learning
> direct debian packages... which means that people often ended up not
> actually learning fully about the real debian package formats.
>
> I see this happening with GAR. It is getting more and more complex....
> and there is more of a movement for people to "learn gar", instead of
> learning what is happening in our Actual Packages.

In fact our package structure gets more and more complex, and GAR helps
*hiding* this complexity from the maintainer.

> I see this as a bad thing.


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.

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.

> I think that GAR should be an "assistant" to making packages, but not
> a REPLACEMENT for understanding packages.
>
> An excellent example, is the recent alternatives GAR module.
>
> To my mind, using the gar module, is almost the same complexity as
> just using alternatives directly!

Funnily the only person complaining that this is too complex is
one of the few not using GAR.

> To do it "directly"; provide ONE FILE, with ONE LINE in it.
> basically:
>
> /opt/csw/etc/alternatives/YOURPKGNAME:
> /opt/csw/bin/userprog userprog /opt/csw/libexec/yourprog  {Priority  
> rating}

I don't see how this is different from the GAR implementation.
This is *exactly* of what you write in ALTERNATIVES_* in GAR.

> then we do basically the same steps as if you were using a
> 'cswclassutil' function.
> Set that file to be class "cswalternatives" in your prototype file,
> add in cswalternatives to the CLASSES def in pkginfo, and depend on
> the appropriate package (CSWalternatives).

All this is done automatically without maintainer intervention.

> It could be nice if GAR somehow auto-detected presense of
> /opt/csw/etc/alternatives/[anything-here], and then automatically did
> the class stuff.

GAR works exactly like that. If you feel like shooting yourself in
the left foot you can just put the file in the right location
manually and GAR will pick it up and take care of the rest.

> However, it is not so nice, in my opinion, that it attempts to mask
> the underlaying package mechanisms from the maintainer.
> Maintainers need to understand how "alternatives" really functions, if
> they are going to use it.

The understanding on how alternatives work has nothing to do on
how you specify it in the package. The current GAR implementation
is not even abstract enough: the final goal is to just specify
the alternative modulations and how they are build (like
"slang" and "ncurses") and what binaries should be switches
(like /opt/csw/bin/mutt) and GAR should take care of the rest
like renaming the real binaries, setting up the modulation etc.
so the current variables ALTERNATIVES_ would only be an
(then invisible) intermediate step.


Best regards

   -- Dago