Hi,
Am 17.03.2010 um 19:48 schrieb Philip Brown:
On Wed, Mar 17, 2010 at 11:12 AM, James Lee <[email protected]> wrote:
Would neon would be better served by an auxiliary flag (see ld(1)).
[...]
This has the effect that when anything looks for libneon.so it will
get libneon-full.so if it exists otherwise just it gets libneon.so
I have made some tests and it looks like just the right solution for the
feature-library problem.
There are multiple cases where we are proposing using the
"alternatives" set of utils for packages:
1. Where there is truely different functionality available, and user
has to choose either/or.
Examples: tcpwrappers libs, and the "ncurses or slang back end" for
mutt.
2. Where there is optionally "enhanced" functionality. In which case,
we allow for "alternatives", mostly to save on download footprint, and
dependancy footprint.
[are there any other cases?]
For categories that fit #2, if there is a clean "use libxxxx-full if
installed" option, it seems like the auxiliary linking flag is
probably the better way to go in most cases.
Some 32 bit/64 bit apps may fall in the same category if they operate
on the same data and when 64 bit is considered better, then isaexec is
the
tool of choice. But this just as a sidenote...
As such, perhaps we should both update the neon package like that, and
also update our "alternatives" documentation, to explicitly redirect
the maintainer to this path when it is appropriate?
I'll do some GAR integration to make this as straight-forward as
alternatives.
However, all this doesn't bring us close to NFS-sharing when
alternatives are used. Suggestions, gentlemen?
Best regards
-- Dago
_______________________________________________
maintainers mailing list
[email protected]
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.
