After some minor rework all patches in gnuplot ebuilds get merged upstream. The ebuilds after gnuplot-4.4.0_rc1 will be "vanilla" (see >=4.4.9999). So my question is, if there is a change to get at least the stable gnuplot branch (4.4.9999) back in the tree. We also have to discuss the multislot use flag.
> After some minor rework all patches in gnuplot ebuilds get merged upstream. > The ebuilds after gnuplot-4.4.0_rc1 will be "vanilla" (see >=4.4.9999). > > So my question is, if there is a change to get at least the stable gnuplot > branch (4.4.9999) back in the tree. Right, we should get the 4.4 release candidates into the main tree. I only didn't find the time yet. Do you suggest that it should still be done for 4.4.0_rc1, or should we wait for _rc2? As for the live CVS ebuilds, I think that the science overlay is a good place for them. Another live ebuild for the 4.4 branch should be added there. > We also have to discuss the multislot use flag. SLOT needs to be static, because it's in the metadata cache. So the following construct is illegal: use multislot && SLOT="${PV:0:3}" || SLOT="0"
> Do you suggest that it should still be done for 4.4.0_rc1, or should we wait > for _rc2? I would wait for _rc2 due to the fact, that the ebuild will hopefully be free of any patches then. > Another live ebuild for the 4.4 branch should be added there. sci-visualization/gnuplot-4.4.9999 is in science overlay, I put it there yesterday. It is what _rc2 ebuild will look like. > SLOT needs to be static, because it's in the metadata cache. So the following > construct is illegal: > use multislot && SLOT="${PV:0:3}" || SLOT="0" I see, just copied the idea from the sys-boot/grub-1.97.1 ebuild. How to proceed? I like to have multiple gnuplot versions to keep consistency in plot styles and fitting errors.
(In reply to comment #2) > I like to have multiple gnuplot versions to keep consistency in plot styles > and fitting errors. Then we should slot it unconditionally. We would need SLOTs 4.2 and 4.4 in the main tree, and in addition 4.5 (or call it 4.6, seems releases all have even minor version numbers?) in the overlay. As far as I can see, the files for Emacs support currently collide between different slots. Not sure what to do about this, maybe it would be easiest not to install them with gnuplot, but to revive app-emacs/gnuplot-mode instead: <http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emacs/gnuplot-mode/?hideattic=0> Do we really need an eselect module, or would alternatives.eclass be sufficent here?
> Then we should slot it unconditionally. We would need SLOTs 4.2 and 4.4 in the > main tree, and in addition 4.5 (or call it 4.6, seems releases all have even > minor version numbers?) in the overlay. Devel versions have odd numbers, release versions have even numbers. > As far as I can see, the files for Emacs support currently collide between > different slots. Not sure what to do about this, maybe it would be easiest not > to install them with gnuplot, but to revive app-emacs/gnuplot-mode instead: > <http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emacs/gnuplot-mode/?hideattic=0> I am not a emacs user, but would it be enough to install lisp files in slotted subdirs? Should the latex support files be separated as well? > Do we really need an eselect module, or would alternatives.eclass be sufficent > here? In the first place the eselect module creates a bin/man/info symlink from gnuplot-X.X to gnuplot. Is this possible with alternatives.eclass as well?
(In reply to comment #4) > I am not a emacs user, but would it be enough to install lisp files in > slotted subdirs? They are identical between different gnuplot versions, so slotting doesn't make much sense (I'm aware that this could change in future, but as long as the interface stays the same it doesn't matter). Also I'm currently not so happy with the compilation of lisp files taking place in src_install. Of course, this was dictated by the need for simultaneous GNU Emacs and XEmacs support. > Should the latex support files be separated as well? Good question. Looks like we could have a multitude of packages: gnuplot, eselect-gnuplot, gnuplot-mode (twice, in app-emacs and app-xemacs), gnuplot-latex. ;-) But seriously, the upstream package doesn't support slotting too well, so we have to decide for each subdir (or file) if we slot it, move it to another package (common for all slots), or do something else. My idea would be something like this: bin: slotted man: slotted info: Just install as gnuplot-${SLOT}.info and fix the dir entry. We don't need a symlink here (see app-doc/elisp-manual for an example). elisp: Move to own package? latex: Not sure about this one. Generally, you want that all concurrently installed gnuplot versions are functional, so LaTeX should be able to process output from every version. This contradicts slotting. (For example, if both gnuplot-4.2[lua] and gnuplot-4.4[-lua] are installed, then gnuplot-lua-tikz.sty should be available, even if 4.4 is (e)selected.) Are you aware of any other distro offering slotted gnuplot versions, so that we don't have to reinvent the wheel?
CVS ebuilds should stay in sci overlay, it is to floating for the tree... I removed the multislot use flag, reopen this bug at any point if it is needed again. The following things do not go nice with multislot support and will always need extra care -info files (move file + change info dir entry) -latex support files (REALLY no multislot support) -emacs support files (extra package) We could think of installing an extra plain gnuplot binary without any support files in a different slot. However, as always, if you need a special gnuplot version, just mask the others.
(In reply to comment #6) > I removed the multislot use flag, reopen this bug at any point if it is > needed again. The following things do not go nice with multislot support and > will always need extra care > -info files (move file + change info dir entry) > -latex support files (REALLY no multislot support) > -emacs support files (extra package) > > [...] > > However, as always, if you need a special gnuplot version, just mask the > others. I'm glad that you've come to the same conclusion as I did. ;-) Slotting gnuplot would have been quite some pain and I'm not sure that the advantages would have outweighed the additional maintenance burden. I believe that most users want the latest or latest stable version, and for "production" environments people can always require a previous version. We can keep 4.2* indefinitely for these users (unless it's killed by some security issue that cannot be fixed). Thank you for your work on the gnuplot package!
