[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jordi Gutiérrez Hermoso
Subject: Re: precompiled 3.4 for Debian/Ubuntu: was Re: still problems, version?
Date: Tue, 19 Jul 2011 15:42:14 -0500

2011/7/19 Uwe Brauer <address@hidden>:
>  > 2011/7/19 Uwe Brauer <address@hidden>:
>  > I've never used auto-apt, but it only seems to install
>  > missing debs detected when building. It shouldn't be
>  > necessary because you installed the build-deps, and if
>  > it *was* necessary, then the build-deps are indeed
>  > outdated and we need to update them for 3.4.
> 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.

>  > 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?
> I don't want to start a flame war or anything like this and
> the reasons you give below seem sound, however for me they
> look valid at a time, where disk space was small and
> bandwidth tiny.

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.

Debian aims to be a Universal Operating System, not an operating
system for people who don't use machines with limited resources or an
operating only for people who live in rich countries with plentiful

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

> How is the situation with rpm, it is so long time ago that I
> used them, are they also parted in many small rpms?

Yes, but fewer. And last I checked (Fedora), they were distributing
monolithic Octave-Forge packages, which are quite outdated.

>  > Ubuntu encourages people to modify their sources.list file to
>  > point to any old repository with little regard for the quality or
>  > safety of the packages installed from that repository. I would
>  > prefer if you didn't encourage Ubuntu users to do this for Octave
>  > packages and instead you helped us update the Octave package
>  > correctly. This is not plain snobbery; it is simple the best use
>  > of our limited volunteer-driven efforts.

> This I can believe, it is that I am forced to consider 3.4
> and haven't found any precompiled packages. What is wrong
> with the approach to have experimental debs for the
> impatient with a big warning message and wait for Ubuntu and
> Debian to catch up?

What's wrong with helping Debian instead of making a quick solution
that works for a few people but not for everyone? The quick and dirty
solutions are often more of a problem than they're worth. I'm not a
fan of shortsighted solutions. Help us with the actual large scale
problem, not only with your problem.

- Jordi G. H.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]