[csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw

[Dagobert Michelsen]

Hi,

Am 17.03.2010 um 19:48 schrieb Philip Brown:
> On Wed, Mar 17, 2010 at 11:12 AM, James Lee <james at opencsw.org> 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