[Pkg-crosswire-devel] links to modules was Re: Debconf question to install modules and other ideas

[Dmitrijs Ledkovs]

2009/1/27 Matthew Talbert <ransom1982 at gmail.com>:
>> On Tue, Jan 27, 2009 at 6:51 AM, Eeli Kaikkonen
>> <eekaikko at mail.student.oulu.fi> wrote:
>>> Quoting Daniel Glassey <dglassey at gmail.com>:
>>>
>>>> The other idea is for ~/.sword to be created with soft links to
>>>> modules in /usr/share/sword and /usr/local/share/sword. Then a user
>>>> can 'delete' the module from there without having to go near apt. The
>>>> library will need to ignore the system directories and only see the
>>>> home dir plus any other custom dirs.
>>>>
>>> I don't like this idea because it alters the old behaviour. I have
>>> used both /usr/share/sword and ~/.sword and would hate if after
>>> updating the distro the modules would be messed up.
>>
>> We'd have to make sure that old behaviour was maintained and worked as
>> expected after an upgrade.
>>
>> I'd expect that modules would be installed with app module manager to
>> ~/.sword and those would be the real files. They would be preferred to
>> the soft linked system modules.
>>
>> I mean that the order of preference is:
>> ~/.sword
>> then /usr/local/share/sword
>> then /usr/share/sword
>>
>> I'm not sure where custom module paths would fit in. I'd guess using
>> the current system either below or above ~/.sword.
>>
>> So the proposed new linking system would only link in files that don't
>> already exist in ~/.sword
>>
>> Does that make sense? Is that roughly how it currently is?
>>
>> Regards,
>> Daniel
>>
>
> I think this entire suggestion is pretty good, but there are still some issues.
>
> If modules are in /usr/share/sword and /etc/sword.conf still lists
> /usr/share/sword for the data path, then if modules are unlinked from
> ~/.sword, they will still be available so they won't appear "deleted"
> for the user. One possible solution to this would be to leave
> /usr/share/sword out of sword.conf and list /usr/local/share/sword
> instead. This would be my preference because I'm fairly sure that
> GnomeSword would behave well with this method. If
> /usr/local/share/sword happened to be writable, then GS could install
> there, otherwise it would install in ~/.sword. I'm not the most
> familiar with how linking works, but I think the module manager would
> be able to delete and index modules linked from /usr/share/sword to
> ~/.sword.
>
> Custom module paths can be used by defining SWORD_PATH which I believe
> would override what is listed in /etc/sword.conf. In addition,
> according to the documentation, extra paths can be added to
> /etc/sword.conf for custom module paths. However, this I can't
> guarantee will work in any logical fashion in GnomeSword.
>
> Matthew
>

Well I feel strongly against making links into ~/.sword

The reason being:

1) For which users install links?

Apt is run as root, so it doesn't really know which user called. Do we install links
for all, one, some, none?

2) A new user is added

There is no way we will be able to detect that and recreate links unless GS does it
for us.

3) User is doing backup

Backups up ~/.sword; goes to new computer untars it only to realise it is full of links

4) As per FSH we shouldn't

Anything  apt installs should got /usr/ and similar

5) We are not like Windows =D Let's not create icons behind user's backs. ;-)
 (replace icons by hard/soft links)

-- 
With best regards


Ледков Дмитрий Юрьевич

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 270 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-crosswire-devel/attachments/20090128/c4ddc3c7/attachment.sig>