Bug#469732: libglpk0: excessive install dependencies
Larry Doolittle
Version: 4.25-1
Severity: wishlist
The 4.27-1 update includes:
* debian/control: Build-depend on libiodbc2-dev and
libmysqlclient15-dev in order to get MathPROG support
Apparently this also adds to the install-time dependencies.
Upgrading to this version, apt-get tells me:
The following extra packages will be installed:
libiodbc2 libmysqlclient15off mysql-common
[chop]
After this operation, 5124kB of additional disk space will be used.
Note that the reason I have libglpk0 on my machine is to run
Octave (octave3.0 depends on "libglpk0 (>= 4.25)").
Since octave runs fine with libglpk0-4.25, I fail to see why
5 Megabytes of new code is required as of 4.27. I'd like to
see Debian dependencies granular enough that stuff like this
can be optional.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages libglpk0 depends on:
ii libc6 2.7-9 GNU C Library: Shared libraries
ii libgmp3c2 2:4.2.2+dfsg-2 Multiprecision arithmetic library
libglpk0 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Rafael Laboissiere
tags 469732 confirmed
thanks
* Larry Doolittle <ldoo...@recycle.lbl.gov> [2008-03-06 11:16]:
> Package: libglpk0
> Version: 4.25-1
> Severity: wishlist
>
> The 4.27-1 update includes:
> * debian/control: Build-depend on libiodbc2-dev and
> libmysqlclient15-dev in order to get MathPROG support
> Apparently this also adds to the install-time dependencies.
> Upgrading to this version, apt-get tells me:
>
> The following extra packages will be installed:
> libiodbc2 libmysqlclient15off mysql-common
> [chop]
> After this operation, 5124kB of additional disk space will be used.
You are absolutely right. I will consider producing two independent library
packages, one with MathPROG support and the other without. I do not know
whether this will be possible, though. In case it is possible, which naming
scheme would you suggested? We could have:
with MathPROG without MathPROG
1st option libglpk0 libglpk-light0
2nd option libglpk-mathprog0 libglpk0
Which would be better?
--
Rafael
Rafael Laboissiere
I am bringing to your attention Bug#469732, filed against libglpk0 version
4.27-1. Since this version of glpk, MathPROG support in GLPK has been
activated. This results in pulling a series of dependent packages related
to iodbc and mysql. I am contacting you because your packages depend on
libglpk0.
I am thinking about generating two separate library packages from the glpk
source and I am wondering which would be the best naming scheme. These are
the options I am considering:
with MathPROG without MathPROG
1st option libglpk0 libglpk-light0
2nd option libglpk-mathprog0 libglpk0
Which would be more appropriate?
Rafael Laboissiere
found 469732 4.27-1
thanks
* Larry Doolittle <ldoo...@recycle.lbl.gov> [2008-03-06 14:18]:
> Rafael -
>
> On Thu, Mar 06, 2008 at 10:39:34PM +0100, Rafael Laboissiere wrote:
> > * Larry Doolittle <ldoo...@recycle.lbl.gov> [2008-03-06 11:16]:
> >
> > > Package: libglpk0
> > > Version: 4.25-1
> > > Severity: wishlist
>
> Note that since I hadn't upgraded (and hope not to until this
> is resolved), reportbug inserted the wrong version, and I didn't
> notice until later. This mistake makes the pretty version
> status images at bugs.debian.org incorrect. I've never messed
> with Debian BTS control; if you don't mind, can you fix it?
Done.
Falk Hueffner
> packages, one with MathPROG support and the other without. I do not know
> whether this will be possible, though. In case it is possible, which naming
> scheme would you suggested? We could have:
>
> with MathPROG without MathPROG
> 1st option libglpk0 libglpk-light0
> 2nd option libglpk-mathprog0 libglpk0
>
> Which would be better?
Just for the record, I don't think this is a good idea. It makes the
package more complicated, users have to waste time with checking out
what they need, while 99.99% will not care about 5M of disk space that
cost about 0.1 cent.
Falk
Larry Doolittle
On Fri, Mar 07, 2008 at 03:02:41PM +0100, Falk Hueffner wrote:
> On Thu, Mar 06, 2008 at 10:39:34PM +0100, Rafael Laboissiere wrote:
> > You are absolutely right. I will consider producing two independent library
> > packages, one with MathPROG support and the other without. [chop]
>
> Just for the record, I don't think this is a good idea. It makes the
> package more complicated, users have to waste time with checking out
> what they need, while 99.99% will not care about 5M of disk space that
> cost about 0.1 cent.
Let's see: a new 500 Gig disk costs about US$100. 5 Meg
is 1e-5 of that, or 0.1 cent. Your arithmetic checks.
I guess you have never operated an obsolete machine on its
last legs, still doing useful work on last-decades technology,
with its disks at 99% full, where upgrading disks would also
mean upgrading the disk controller, and maybe installing a
new kernel to support that controller. Cost of each extra
5 Meg is zero, until the cumulative effect forces an upgrade,
which costs both real money and system downtime.
A Debian system where sensible package granularity lets people
install what they need: priceless.
I am an Octave user, and only install libglpk because it is
an Octave dependency. I haven't yet done any linear programming
within Octave, but it's nice to know that will work if I ever
need it. Does adding MathPROG to libglpk benefit me in any way?
I honestly don't know, I haven't done the research.
- Larry