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

[Isaac Dupree]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonas Karlsson wrote:
> 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.

How about NON-dot files.

System/Links/Libraries/curl.h
System/Links/Libraries/curl.h--ProgOther-3.4
...

(If conflicts include multiple versions of the same program, this might
get ugly...) otherwise it only shows ugliness where there is ugliness,
which isn't that often and is good to see when you're looking in there
for some reason.  (I'm too ignorant about conflicts and such to know
whether that made good sense.  And not listing the active program among
the alternatives still bothers me a little, but that would mean
non-conflicting symlinks should logically be annotated...)

Isaac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGh6PAHgcxvIWYTTURAmWyAJ9TnooRwi3YBR8yNkS6xK1QU1LVPwCgmfme
DrxuwplG6Cw8yjEoWLqH5Mo=
=KfIU
-----END PGP SIGNATURE-----