Hi Phil,
Am 12.04.2010 um 22:38 schrieb Philip Brown:
....
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 :)
This is about defaults, not hiding implementation details. That
only including libraries per default would be more intuitive may
be true and I already wanted to do it, but I fear breaking old
recipes. We may start another thread on how to best do this.
Unfortunately, it does not seem possible to make providing an
"alternatives" implementation in a package, "automatic".
I haven't done it "automatic" because I simply don't have enough
usecases. There is barey one package for each usecase and this
is just not enough for me to generalize out "the best default".
or even "simple".
I have added an example for the most simple case: one alternative
in one package:
<http://sourceforge.net/apps/trac/gar/wiki/Alternatives>
However, this also was not in there because there was no use for it.
The existing packages all use the other documented mechanisms.
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.
Again, we didn't have that case up until now and I just added the
necessary line in GAR:
<http://sourceforge.net/apps/trac/gar/changeset/9632>
So, me going along with the idea of "Gar really does make this
easier".... would you please simplify your wiki page about it?
Done.
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?
We already have this documented in the general "How alternatives work"
wiki. As it is said on top of the trac wiki page you are supposed to
read that first. Every argument to GAR is exactly of what is passed
to alternatives with the --install added automatically.
Best regards
-- Dago
_______________________________________________
maintainers mailing list
[email protected]
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.
