[gobolinux-users] Solution for situation when more programs provide same file

Jonas Karlsson jonka750 at student.liu.se
Sat Jun 30 18:20:46 UTC 2007

On Sat, 30 Jun 2007 19:57:11 +0200, <hisham.hm at gmail.com> wrote:

> On 6/29/07, mpb <mpb.mail at gmail.com> wrote:
>> On 6/29/07, Carlo Calica <carlo at calica.com> wrote:
>> > On 6/29/07, mpb <mpb.mail at gmail.com> wrote:
>> > >
>> > > My concern is that creating .Alternative in the current Links
>> > > subdirectories files feels dirty to me.  What if some Program actually
>> > > has a file named .Alternative...?
>> > >
>> > > How about symlinks as follows:
>> > >
>> > > System/Links/Conflicts/ProgramA/lib/libfoo.so ->
>> > > System/Links/Conflicts/ProgramB/lib/libfoo.so ->
>> > > etc.
>> > >
>> > > Or alternatively:
>> > >
>> > > System/Links/Conflicts/Libraries/libfoo.so/ProgramA-1.0 ->
>> > > System/Links/Conflicts/Libraries/libfoo.so/ProgramB-3.4 ->
>> > > etc.
>> > >
>> >
>> > Conflicts is a better name than Alternatives.  Matches existing
>> > nomenclature better.  Not sure about turning each conflicting file
>> > into a directory.  I REALLY like how the original package is named so
>> > you don't need to look where the symlink is pointing to.  The previous
>> > proposals have an incrementing counter which I don't like.  Long lived
>> > installs would have .Alternative13432424--libfoo.so which gets
>> > unwieldy fast.  Reclaiming unused numbers is an option but adds
>> > complexity.
>> How about:
>> System/Links/Conflicts/Libraries/libfoo.so--ProgramA-3.4 ->
> Yes, naming the program is better than the number. Keeping the
> extension in the end (as suggested elsewhere in this thread) isn't
> needed because (a) the file isn't being really used as a library, the
> symlink itself is merely data for the conflicts system, and (b) what's
> an extension in Unix, anyway (you don't want foo.tar--blabla.gz).
> I don't like the idea of separating files and conflicts into two
> trees, though. I'd rather have dot-files. If I'm in
> /S/L/Headers/curl/curl.h and I want to take a look at its conflicts,
> it feels a lot easier to do a ls .c<tab> than to navigate to ls
> /s<tab>/l<tab>/c<tab>/h<tab>/c<tab>/c<tab> (or something like that).
> The use of dot-files would keep fs view clean.
I too like the one suggestion from mpb that you selected above. Because I
think that the most important part within this problem is the filename,
therefore this should be the primary attribute. Then comes the originating
application name and version.

I do like a separate tree instead of dot-files, as dot-files has ability
to become lost or forgotten about, as it's hidden from view almost all
the time.
Having a separate tree is easier, because then you'd know where to look.
There are two approaches, what I can see. Either
/System/Links/Conflicts/Libraries or /System/Links/Libraries/Conflicts.
The latter is only to make it easier for Hisham to list conflicts (j/k),
as he would only have to do ls C<tab>c<tab> (unless there actually exists
a file or directory that begins with a capital c). To be serious, this is
the downside of the latter approach; there might be a file or directory
called Conflicts inside an application's tree (very, very unlikely) and I
don't like the idea of having the same named directory within every links
directory. So my vote goes to the former. :)
Listing conflicts isn't that much harder than with dot-files:
ls ..<tab>C<tab>c<tab>
And is this really a real problem? How often would one want to list
conflicts? Really?


Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

More information about the gobolinux-users mailing list