Re: precompiled 3.4 for Debian/Ubuntu: was Re: still problems, version?

[Uwe Brauer]

>> 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


   >> > 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. Of
course if the authors of octave chose to have it this way it
does not make sense to pack it into a single monolithic
pkg. But also vice versa if certain structure is monolithic
by design choice it should be respected.

   > 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.

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?

   > 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?

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? 
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?



   >> > 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. It is of course completely unacceptable to offer
       code which runs on say my machine but cannot be
       installed smoothly on another machine due to
       unresolved dependencies. Here I agree with your
       completely. I really would like to learn how to do
       this correctly,
       http://pkg-octave.alioth.debian.org/DOG-Guidelines.html
       gives my guidlines but I would like to have more details.

    -  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]

    -  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.







Footnotes:
[1]  (X)emacs is a bad example of this.