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

[Philip Brown]

So, I saw a recent mail, I think from Dagobert, about how to enable
"alternatives" use in GAR.
Unfortunately, I cant find the specific email, or I would quote it :(

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.

I see this as a bad thing.

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!

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}


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).



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