Sorry for having been offline the last days ... On Sat, Dec 15, 2001 at 03:17:14AM +0100, Sven wrote: > On Fri, Dec 14, 2001 at 08:44:17PM +0100, Ralf Treinen wrote: > > > > I guess that in most of the cases the package maintainer an decide which > > of the two he wants to apply for his package. > > > Why not compile both and let the user be the final judge of what he want. > > With a clever done diversions tuff, i guess the package maintainer could > strongly hint at one solution he consider best, but leave the user the > possibility to override this, possibly with a debconf dialog or something > such.
I think that providing two versions for every application package is in many cases an overkill. It will double the number of packages written in ocaml (which aren't too many for the moment, but who knows). While I aggree that there are cases where it makes sense to provide both I tend to say that in most cases the package maintainer can make a decision whether he wants to provide a bc or native package. If execution speed does not degrade too much then I would consider to build my package as bc. > > True, this makes a bit more work for the packager, and may not be worth it for > some packages (especially the really big ones, like maybe coq), but you can > not think of al the possibilities that can cause the user to choose one or the > other. Well, in some sense this is the point of building a software distribution. You as a package maintainer have to decide which are the build options that make sense for your typical users. There is a tradeoff between customizing everything yourself and using a standard. Thinking of bibtex2html, for example: Bibtex data bases are restricted in size to <= 5000 entries (or something like this) anyway (this is a restriction of the bibtex program). If a bytecode bibtex2html runs reasonably on this then I will build the package in bytecode. True, a user might use the bibtex format to build some other application data base which has nothing to do with bibtex, and then run bibtex2html on it. If there are 1 or 2 users with such special needs then too bad for them, I cannot build a custom package just for them. > Imagine a new shiny i386 processor, for which the shipping ocaml has a > broken native code, or something such other unlikely. This is of course different. If one of native or bc is broken on one architecture then the maintainer should be able to use the other option on this architecture. BTW, Judicael Courant is curently implementing for the coq package a mechanism that attempts to build the package in native, and to rebuild in bc if the native compilation fails. Having said that I agree that thre might be cases where it make sense to build both a native and a bc package. However, I would like to have the maintainer decide what is sensible in his case. Remains the interesting question on how to build packages that come in a native and in a bc version. Sven suggested using diversions, there is also the possibility of alternatives. I have never used any of them in my packages, and I don't know which of them to prefer. Alternatives seem to be less trouble to use, though. One could imagine another possibility for providing for both of a native and a bc executable: one could imagine a directory "/usr/share/bin" which contains architecture independent executables - like ocaml bc, shell scripts, perl (!) scripts, ... If this directory comes after /bin and /usr/bin in a users path then he will automatically give preference to a native version in /usr/bin to a bc version in /usr/share/bin. The FHS does not mention a directory /usr/share/bin. Maybe I will ask on debian-devel what people think of it. > BTW, you would need to depend on the ocalk-base package, but also on the > shared stubs libraries of all the non pure ocaml packages you depend on. Maybe > in this case, the -base postfix was ill choosen, or we should split off > libraries with -runtime or something such, including the shared libraries > needed for them. Does version 3.04-2 of the runtime package contain the libraries that are used by the runtime system? bc packages loose a lot of their potential advantages when a user needs to install the ocaml development package to run them. Best seasonal greetings to all of you -Ralf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
