Pascal Georges wrote:
Hi!
> Point is, if you assume a Unix installation, scid is
> owned by root and not by the user. And thogh bases and
> books are an exception there're still some files with
> scid that are kept "for the site" and not "for the
> user". Usually these are spelling/rating files, player
> photos, move announcements. And these live in
> .../share/scid. (Though I do not use the data subdir
> there.) Scid should find them by default if packaged.
>
> Actually, this type of setup common on a decent unix
> is the reason why I'd vote for distributing books and
> bases in a separate package. Both type of files
> should be user-writable while e.g. move announcements
> don't.
>
>
> The bases are installed for every users, and they are
> writable by all users, which may cause conflicts but I
> don't think those files should go in users directory.
Well, you'd hardly allow somwhere/share/scid/bases to be
owned by root:users with permisions rw-rw-r-- on a multi
user system. It can "cause conflicts", but thats the lesser
problem here...
Normally, I install them root:root rw-r--r--. If the user
wants to change bases or books he has to copy them. They're
personal in that regard then anyway. They're just installed
to the general share dir for the user to be able to copy
them painlessly and to probably revert to the original
state without problems.
> The drawback with two packages is that many users will
> forget the data package,
A nice way to solve this could be a "fetch" function in scid
that can get such packages from the web. It's probably worth
considering as it could be enhanced to some training
management or something like that. E.g. putting some
exercises on the web on some timely basis for download.
Also, the distribution of major events could be managed by
such things. (E.g. fetching TWIC automatically is pretty
similar.) But this is just an idea, not really thought
through.
> and I don't like the applications that needs tons of
> packages before being usable.
Well, you stick to the Windows approach here. I prefer very
fine grained packages, as they can be found in Debian e.g.
> To avoid forgetting extra packages, a dependency can be
> set, but then why not building a simple package ?
Simply cause I can use scid without these files and it
might happen that I do not at all need them, because I've
them or other such files in my personal data already. Then
there is no need to install them.
Besides saving diskspace (which I'd call an economic reason)
its a bit philsophical. Take e.g. a SuSE distribution
compared to Debian. SuSE follows your idea. They install tons
of stuff I never need, requiring me to get rid of it again
or live with the wasted space. This has the advantage that
the user almost never needs to add anything. Debian on the
contrary will install a very small system but requiring me
to add this or that package over time if I need it.
> Having said that, I personaly always use Scid from my home
> dir, and never run "make install" it ...
I was very sure about this. No offense, but you've a very
Windowish attitude towards Unix ;)
I always install the release versions as root to /opt/chess.
It gets a bit philosophical here, though ;)
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users
