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

Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package



On Fri, Jun 28, 2002 at 07:19:59PM +0100, Ian Jackson wrote:
>  Version B (Anthony and Manoj, I think):

For reference, I'm actually with Ian on this issue; I don't see much
point creating a new package for cardinfo and dealing with the hassle
of cardinfo disappearing on an apt-get dist-upgrade and such like. But
I'm also not on the tech ctte, so *shrug*.

On Sun, Jun 30, 2002 at 10:42:32PM -0600, Bdale Garbee wrote:
> In discussing this with Manoj on IRC, I realized that arguing in favor of
> tolerating broken run-time dependencies wasn't really a position I wanted to
> take.  So, when the question is called, I think the only "right" answer is to
> expect packaging to cause run-time dependencies to be fulfilled, suggesting 
> that in this and similar cases splitting the "offending" binary into a 
> separate package that pulls in the "extra" dependencies is the right thing 
> to do.

It's a pity we're going with votes and committee rulings when we can't
establish a consensus on something that's clearly the right thing to do.
Oh well. I'm still interested in how such a view affects other packages
that do similar things:

	* debconf frontends -- all are included in debconf.deb, some
	  are only available/functional when other packages are
	  installed. In the event that one isn't functional, debconf
	  falls back to other frontends. This can be "fixed" (if it's
	  considered broken) with the same cost as cardinfo.deb, a
	  handful of tiny packages.

	* ifupdown methods -- "iface eth0 inet dhcp" will only work
	  if you've got one of various dhcp clients installed, otherwise
	  it'll... hrm, not do anything not even give you an error.

	* kernel modules etc -- a bunch of programs depend on the kernel
	  being configured a certain way (CONFIG_PACKET and CONFIG_FILTER,
	  eg), or particular modules being loaded in the running kernel,
	  and you can't ensure that they work no matter what you do with
	  dependencies and other packages.

Should any of the above be changed too? Should the Readline and
Gnome, frontends all be packaged separately with appropriate depends
(libterm-readline-gnu-perl, libgnome-perl, respectively) to ensure
they're functional if they're installed?

It's a pity we still don't have better support for splitting packages
in apt/dselect than adding a Depends: from the old package to the new.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

Attachment: pgpum6vnIUXvk.pgp
Description: PGP signature


Reply to: