Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Anthony Towns writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package"):
> 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*.
Quite.
> 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.
I agree.
> Oh well. I'm still interested in how such a view affects other packages
> that do similar things:
I would very much like those who broadly support the version B to
answer these questions ...
> * debconf frontends [...]
> * ifupdown methods [...]
> * kernel modules etc [...]
... and other similar ones I asked on the 27th of April:
] * cron Recommends mail-transport-agent. [...]
] * fvwm Suggests m4. [...]
] * minicom Suggests lrzsz. [...]
] * groff contains gxditview, [...]
I think that to support version B you have to either say that
(i) a non-core part of a package that is a separate executable and
which fails to start with a dynamic linker error is much worse than a
non-core part that is a menu option, configuraton option, sub-CLI
command, etc., or a failure of an executable to start for some other
reason (kernel feature missing, lack of DISPLAY variable, some
subfeature of some other program being disabled, or even the very
option being disabled by configuration ...)
(ii) all these other examples should be changed too, producing
zillions of extra little packages and requiring dynamically generated
menus and command lists in all sorts of configurations.
In fact, as I've said before, I think what's happening here is that
some people are unwilling to tolerate error messages, and intend
instead to make the error messages go away by hiding away the ability
to request the non-working feature. This will just make it harder
rather than easier for a user who wants the feature to make it work.
> 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?
Quite.
> 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.
Replaces: is supposed to do this. grep the dselect source for fixme ...
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: