Currently dev-lang/swi-prolog-lite contains both lite and full versions of the swi prolog compiler. It's somewhat confusing to have full versions in a directory named -lite. Reproducible: Always Steps to Reproduce: 1. 2. 3.
*** This bug has been marked as a duplicate of 114379 ***
I don't see how this is a duplicate of 114379. This bug is a request for a new subcategory to be included in dev-lang. Currently both lite and full versions of swi-prolog are in dev-lang/swi-prolog-lite. I think this is confusing and the addition of the subcategory dev-lang/swi-prolog to the portage tree for full versions seems to make more sense. i.e.: dev-lang/swi-prolog-lite for pl-lite-5.0.10 dev-lang/swi-prolog for pl-5.* Alternatively, the dev-lang/swi-prolog-lite subcategory should be renamed to the more generic dev-lang/swi-prolog.
Use better summary next time...
Hi, I second this request. If however maitining two versions requires too much effort maybe a single "full" version only may be an acceptable alterante solution. Thanx.
Ok, lets see what we can do here. I see two possible ways to handle situation: 1. We do the split, produce swi-prolog and swi-prolog-lite packages. For that we need to make sure package installs do not intersect - that is they do not have common files. I went through bug #116567, does that one contain ebuild for only a full version, without -lite? Looks like the package install scripts are smart enough to put binaries into versioned and arch specific location, however the split will need to be complete for all the other files *and* we will need to produce some selection tool, either a module to eselect or something akin gcc-config, which would be called swi-prolog-config I guess.. 2. We do not split, instead we just add some useflag, to enable either lite or full functionality. The problem here is that the choice is 3fold in general, and use flags are binary. That is, user may want to have either full or lite or both.. Having two user flags is ugly, but if you do not expect much demand for having both installed a useflag is feasible to select which one is built and installed. Doing it this way we will not need to worry about clean split, avoiding the need to move files around during install, thus alleviating the need for config utility and, possibly, for an eclass to handle proper support of libs or whatever is necessary to build dependant packages.. Now, the real question is whether lite and full provide similar functionality, so that all swi-prolog deps can be built with both or not. If yes, then we can go with an option 2, as it is easier to maintain. The only thing we will be forcing on users is having only one of these installed at a time, which may not be that bad of a tradeoff (but it is for you to know better). In fact that restriction may be lifted rather easily, it will just not look as elegant useflag-wise.. If they do not both provide sufficient functionality then we clearly need to split, as some packages will have to depend on lite and some on full (and some on virtual).. This implies all the "niceties" I described above (including eclass, to handle proper path/library selections) and will likely significantly delay sorting out the situation with swi-prolog. Just take a look at the toolchain.eclass if you feel brave enough ;). I will be implementing something similar for gnat (Ada compiler), so I'll get some "experience" writing these beasts, but this mainly happens because we have to, not because I am looking forward to it :). George
The "full" versino of swi-prolog comprises the prolog interpreter and compiler along with the many additional packages such as chr, jpl, xpce etc. swi-prolog-lite comprises just the prolog interpreter and compiler. From pl-5.6.0/packages/README: "The package directory contains a subdirectory for each SWI-Prolog package. Without packages, SWI-Prolog is called SWI-Prolog/lite." Historically, along with distributing the full version tarball, upstream also used to tar up the interpreter and compiler and call it prolog-lite. Alas for the bandwidth impaired this is no longer the case, and their is now only one tarball per release - the full version. Since both the full and lite versions install exactly the same prolog interpreter, compiler and associated documentation, I think using a "minimal" USE flag would be preferable to having blockers on two swi-prolog packages. The ebuilds in bug #116567 do contain a minimal use flag that if enabled will cause only the compiler and interpreter to be installed. What we will still need to be address is renaming dev-lang/swi-prolog-lite to dev-lang/swi-prolog. Currently dev-lang/swi-prolog-lite is inconsistent containing the following ebuilds: 5.0.10 (lite) 5.1.13 (full) 5.2.11 (full) 5.3.14 (full) 5.4.7 (full) 5.5.39 (full) Keri.
Thanks for this explanation, and sorry, I was confused by the beginning of this bug and by doing actual split elsewhere.. Then it is quite easy in fact. We just need to finish the work with swi-prolog-5.6.0 and rename the package. Since the 5.6.0 is tracked in #116567 should we perhaps close this bug? With "splitting" decided on the only thing that's holding that version is point 2 of comment 11 in that bug, - the one regarding latex2html.. George
Ok, that's good. I'm closing this bug as bug #116567 now covers all outstanding issues regarding full and lite versions of swi-prolog.
