Re: [Pkg-octave-devel] Packaging Octave 3.8
On Fri, Dec 13, 2013 at 18:45:43 +0100, Rafael Laboissiere wrote:
> * Mike Miller <mtmiller@debian.org> [2013-12-13 09:44]:
>
>
>> On Thu, Dec 12, 2013 at 20:10:22 +0100, Sébastien Villemot wrote:
>>>
>>> Le mercredi 11 décembre 2013 à 11:41 -0500, Mike Miller a écrit :
>>>
>>>> In your plan, what do you propose to do with the oct-files that are
>>>> currently in the octave package? Because both octave and octave-cli need
>>>> those files, either octave-cli would have to depend on octave, in which case
>>>> there is again no need for an or-dependency, or the oct-files would also
>>>> have to be split into a new package.
>>>
>>>
>>> I guess the solution would be to put the oct-files into octave-cli, and
>>> have octave depend on octave-cli. Thus people who don't want the GUI version
>>> would install only octave-cli.
>>
>>
>> This seems awkward, but would work.
>
>
> I vote for Sebastien's proposal and do not see it really as an awkward
> solution. Actually, octave-cli would be a "poorer" version of the
> full-featured octave package. Installing the last one will provide both CLI
> and GUI interface, with GUI being the default. This is what the upstream
> authors intend and what would be the reasonable expectation of our users.
I think we agree, I believe the intention of upstream is that the GUI
executable is the primary executable for most users. It can run in both
GUI and CLI mode. The separate CLI executable is provided as a fallback
for limited systems or restricted environments. A poorer alternative, I
agree completely.
The thing I think is awkward is having octave depend on octave-cli just
because that's where we happen to stuff the oct-files. Rather both are
more like alternatives with different levels of functionality. I'm
comparing with emacs, gnuplot, or vim packaging for what seem to me like
similar packaging models: emacs does not depend on emacs-nox,
gnuplot-x11 does not depend on gnuplot-nox, etc.
Anyway, the pressing question is still whether to split the package at
all, and I took Thomas' point that we should have some analysis. I
tested installing octave 3.6.4 and 3.8.0~rc1 in a clean unstable amd64
chroot to compare dependencies and disk space. I hope the following is
useful.
Installing octave 3.6.4-4+b1 from unstable
204 packages, 93.3 MB download, 355 MB installed
Installing octave 3.6.4-4+b1 from unstable, no recommended packages
86 packages, 29.5 MB download, 104 MB installed
Installing octave 3.8.0~rc1-1~mtm locally built
223 packages, 144 MB download, 455 MB installed
Installing octave 3.8.0~rc1-1~mtm locally built, no recommended packages
115 packages, 88.4 MB download, 230 MB installed
For most users (without --no-install-recommends), the required disk
space goes up by 100 MB, roughly 30% on this minimal setup, mostly due
to the new dependencies. The core octave packages themselves
(liboctave[12], octave, octave-common) increase by 6.3 MB taken
together. The remaining increase is from Java and Qt and their
dependencies. Java pulls in 9 new packages with a total installed size
of about 64 MB. Qt pulls in 10 new packages with a total installed size
of about 30 MB.
Notes:
* LLVM is a new direct dependency, but is already installed on a
recommended install, as a dependency of libgl1-mesa-dri which is
recommended by libgl1-mesa-glx. This one package accounts for another 30
MB increase when comparing the --no-install-recommends upgrade.
* The new Java dependency is more than twice the size of the new Qt
dependency, but this replaces octave-java, and for current users of
octave-java the increase is a wash.
* It has also been discussed on this list to remove qtoctave from the
archive, and for current users of qtoctave the increase due to Qt
dependencies is also a wash.
* The Qt dependencies are only for the GUI currently, but upstream has
discussed adding Qt plotting support, potentially replacing FLTK, and
that might make it harder to split the Qt components in packaging future
versions.
I can provide details of the methodology I used if people are
interested. I have not yet compared runtime performance of the CLI and
GUI executables.
Cheers,
--
mike
Reply to: