Re: precompiled 3.4 for Debian/Ubuntu

[Jordi Gutiérrez Hermoso]

This is my last public response. If you want to continue discussing
this, we should take it off list.

2011/7/20 Uwe Brauer <address@hidden>:
>>> Regarding Re: precompiled 3.4 for Debian/Ubuntu: was Re: still
>>> problems, version?; Jordi Gutiérrez Hermoso <address@hidden>
>>> adds:
>
>  > 2011/7/19 Uwe Brauer <address@hidden>:
>  >>
>
>  >> Another issue, after building and installing I wanted to
>  >> save a graphic and it turned out that I had to install
>  >> pstoedit and epstool
>
>  > And that's only what you've noticed doing one installation on one
>  > machine by one user. You will notice many more packaging problems
>  > when all of these factors are multiplied by hundreds or thousands
>  > of users.
>
>
> Yes but you seemed to have misunderstood me, I think this is
> a bug.
>
> shouldn't apt-get build-dep octave3.2
>
> Have installed these 2 packages already? As I said I had octave 3.2
> installed previously and run into the same problem

No, the octave3.2 package has those two as runtime dependencies
indirectly through other things (well, a library that does the same
thing). I was able to produce plots with gnuplot with the old
octave3.2 package. If you install this package, do you still see this
problem? I don't. Or do you mean with the fltk backend? I don't think
fltk was able to print plots at all in the 3.2 series; Ben Abbot and
others worked hard on the fltk printing features after the 3.2
release.

>  >> > Because people want to install Octave in clusters, so why
>  >> > should we force them to install the documentation on every
>  >> > cluster, in both HTML and TeXinfo? Why should people that
>  >> > don't intend to help us debug wait longer downloading and
>  >> > installing the debug symbols, which are almost eight times the
>  >> > size of Octave itself? If you are not going to be building oct
>  >> > files, why should you also need Octave's headers? Why should
>  >> > every single Octave-Forge package be installed, some of which
>  >> > may be broken, as is or was for a long time the case oct2mat
>  >> > on the Windows distribution, and many are in fact incompatible
>  >> > with each other and with core Octave functions?
>  >>
> Now wait a moment, I am only talking here about octave
> source code which I downloaded from sourceforge. You seem to
> talk about additional packages provided by octave-forge.

Those two are the same.

>  > Bandwidth is still tiny in many parts of the world (e.g. South
>  > Africa), and disk space also is when you need to large
>  > distributed installations or in portable systems.
>
> And may be bandwith is even tinier in say Niger (no offense
> intended) aeh well by this argument debian should not ship
> say openoffice, because its parts are huge.

It should be packaged, but it should also be modularised for many use
cases. Which it is. You can install just the writer or just the
spreadsheet without installing all of OO.o.

> But what is huge? The deb I generated with checkinstall is
> just about 27 Mega (maybe I did something wrong during
> checkinstall installation because checkinstall offered and
> recommened not to install certain files, which I accepted,
> octave runs so far without problems.) Is this huge?

No, but if you include all debug symbols, it increases in size by
almost one order of magnitude. The debug symbols package I see here is
60 megabytes to download and 174 megabytes installed. Even here in
Mexico with my usual "high-speed" internet, that's often about 30
minutes to download, which I don't normally want to wait for. The
octave3.2 package itself is 9.5 megabytes to download and 27 megabytes
installed.

You're saying we should increase everyone's Octave installation size
by 744% because it's easier to package this way? Or should we not
package debug symbols at all?

>  > You also ignore the other fact that some of the Octave
>  > packages simply are incompatible with each other, and
>  > that this has given us a big headache on Windows with
>  > oct2mat, to give one example.
>
> I don't understand: when I download, compile and octave from
> scratch, this results in packages which are incompatible?

No, in Octave-Forge packages that are incompatible with each other,
and which have frequently been requested to be installed all together.

Also, Octave does not exist in isolation. There are very few users who
use Octave without Octave-Forge. A Debian package also has to fit in
general with the entire Debian OS. There are other non-Octave Debian
packages that depend on Octave, and our updated packaging will
probably break those, which is inevitable, but we shouldn't break them
too much and if possible, we should try to give them upgrade paths. A
number of Octave-Forge .debs will probably also break, as we have seen
reported here in the mailing list. There are many complications to
take into account, and creating a single giant .deb that packages
"everything" is not a solution.

> To put it from another perspective, the octave authors ship
> code which can be compiled and installed as a "single
> pkg". Well if this is the authors intention why changing
> it?

It's not our intention. There are many different ways to package
Octave, and it's our intention that packagers decide how to do it.

> Wouldn't it be better to add scripts and infrastucture to
> the octave code, such everybody can generated his own deb,
> rpm etc package, but such that the dependencies are resolved
> by these scripts?

No. Because we cannot predict what everyone will want to do with the
package. It is up to the packagers to decide what to do. Upstream
that ships its own debian/ directory is typically first stripped off
the debian/ directory and repackaged.

>  >> > I know this seems like unnecessary complication from
>  >> > the outside, but it's not. Every person has
>  >> > different needs, and Debian needs to cater to many
>  >> > different needs, plus 11 different architectures. A
>  >> > personal .deb package is fine for personal builds,
>  >> > but it won't satisfy our users, and you can't ignore
>  >> > the complexity that building a proper package
>  >> > entails.
>
> In my eyes there are two problems,
>
>  - generate deb which such that apt-get or dpkg resolves
>    correctly the dependencies. I don't know whether
>    checkinstall is enough for this, my feeling is it is
>    not.

No, checkinstall is only good for personal .debs, it does not create
by any means .debs that are suitable for distribution.

>  - but as far as the monolithic vs module approach is
>    concerned I am not sure I agree with you. For me its
>    best to follow the intention of the octave authors
>    and not complicate things worser but adding more sub
>    structure.[1]

Our intention is to let packagers modularise everything. jwe himself
has frequently said how he prefers this approach, especially with the
Octave-Forge packages.

>  - for me at the moment the learning curve for the
>    octave deb pkg is to steep really decide to help the
>    team, because I think it is better to have none than
>    incompetent help.

Yes, it's hard work. Which is why it's taking me a while to do it. I
build Octave almost every day, often several times per day, but making
a proper .deb out of it is not a trivial task.

Let me reiterate, if you want to help, read the Debian new
maintainers' guide. That has a lot of details that our Debian Octave
Group webpage takes for granted that you already know. I'll be working
over the next few days updating the webpage so that it's easier to get
into packaging, but please understand the complexities of packaging
and why "works for me" is not the same as "works for Debian".

- Jordi G. H.