Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
I prefer the 2nd position in the following issue.
(BTW, I don't subscribe to debian-policy list currently,
Just read this via newsgroup linux.debian.policy.)
In <[🔎] 20011114220401.BC225DF6C@ariel.local.net>,
on Wed, 14 Nov 2001 23:10:11 +0100,
on Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package ,
brian@debian.org (Brian Mays) wrote:
> My argument is as follows:
>
> Programs fail to run for all sorts of reasons and often do not give
> friendly error messages, help text, etc. Problems are not only caused
> by missing libraries, but also missing data or other executables that
> the program expects to run. I fail to see the difference between a
> program that is useless because a library is missing and a program that
> is useless because it is a frontend for another program that is missing.
> The program in question does not even need to be useless altogether;
> many programs fail in unusual or confusing ways when the user activates
> an obscure feature of the program that requires data or other programs
> that are missing.
I have similar problem with my package of sgmltools-lite.
The main program in this package does conversion from
Docbook dsssl SGML source into verious output format
such as html, text, postscript and pdf.
At first, this package just describes the required
packages for only html output in Depends: line.
Then, a few users requested that I should add other
packages for all (text, postscript and pdf) output
formats into Depends: line. I followed that advices.
(related to #75530, #88607, #91981)
After that, I have another bug reports about the newly
added packages in Depends: line. It says that was
a purely extra bloat for users only needs html conversion.
So I reverted to use Suggests and Recommends for required
packages in other than html conversion.
(#92161 and #92212)
In the end, I have #112796 opened wishlist. I don't have
any clear idea what is the best for us.
Spliting into multiple pakcages is an idea, but I don't
want to have sgmltools-lite-{all,htmlonly,html_and_text,etc}
just to declare different dependencies.
> Therefore, for consistency sake, we should do one of two things:
>
> 1) Ensure that no program is installed in a state in which it can fail
> due to missing components, whether they are shared libraries required
> by the program, missing data, or other programs that are used by the
> scripts or programs in the package. IMO, this leads to excessive
> dependencies, since all packages will need to use "Depends" unless
> the dependency is truly external and superficial. Many packages will
> need to be split into tiny sub-packages to keep these dependencies
> manageable.
If this is the way to go, then there may be users who object to have
extra (unnecessary for them) packages installed on their system.
> 2) Allow some components of a package to fail, as long as they are not
> essential to the package's major functionality. With this approach, we
> can group related components into one package and thereby simplify the
> task of package selection, a process that becomes more complicated each
> year. The purpose of each package is to provide a particular service or
> function, not to provide a particular program.
>
> In the second case, "Recommends" and "Suggests" become true
> dependencies; they indicate other packages that are required to get
> additional functionality from a particular package. With the first
> approach (requiring "Depends" almost exclusively), these two fields
> merely become opinions of the maintainer, pointers to packages that he
> or she thinks are "neat" too.
Again, I prefer this approach. I think we should make use of
already established multiple levels of dependencies such as
"Recommends" and "Suggests" as much as possible.
Regards.
--
Taketoshi Sano: <sano@debian.org>,<sano@debian.or.jp>,<kgh12351@nifty.ne.jp>
Reply to: