Pascal Georges wrote: Hi!
> My opinion on binary releases : > - build scripts should be incorporated in Scid repository, > easying maintenance, This is somewhat into the direction of adding --debian/--fedora/--whatever flags to the configure. Of course external script are in order as well. Agree here. > - I'd prefer not putting links to pre-built packages on > Scid's SF site, simply due to maintenance reasons. But > those links are of highest interest to end users, so if > someone wants to take care of this, this would be a good > thing (for example an external link that could be referred > statically from Scid's site) I do not get how you want to set it up: Scid links to http://www.somehwere.org/scid-binaries/ and the list is maintained there? You think probably of a Wiki-like target for this so everybody could hook up links to his individual builds? Or do you think of a page within scid.sf.net/scid-binaries that just contains links off-site, that might be broken some day and just need to be checked from time to time? > - be careful when stripping Scid (books, DB, etc...) as it > breaks some features, and I don't like this. Actually, some parts of scid would plainly not allow it to make it into some distributions if it's not removed. I learned that Nalimov-code is a problem, books are sometimes regarded as "unclear" and for that thrown out. Bases similar. For the engines the feedback was: "its better if one can use what is there from other sources and keeps that part to the absolute minimum." I think, the Bases and Books part could only be overcome by a "Scid Referenence Database" (CentriScid was a name for this recently) and a "Scid Reference Opening Book" (call it ScidBook for the time being). Here also another free book could be used e.g. Harry Schnapps book (if someone has a contact there...) The other alternative to cope with "non-free stuff in pure GPL distributions" is to set up fetch scripts that notify the user that they are installing non-free parts and then fetch them from the net. Debian does things like that for TTF-Corefonts by M$, Win32-plugins for MultiMedia, some hardware drivers that contain closed source components and so on. This would then require a centralised fetch URL at scids site and mainly come back to a suggestion that I made some time ago, namely remove all these packages in question from core scid and add a simple fetch function into scid itself so it can retrieve these parts upon request. Say, the user selects Play/Training/Opening, no suitable database is found but a list is offered "you may fetch the follwoing predefined DBs from scids website." Which then initiates a download and install into userspace. (Jose handles opening books that way. One of the few parts that work pretty well in Jose I might add.) If scid e.g. first gets back some structure of the offerings it could be pretty flexible. -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
