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

Packages: pcmcia-cs, tech-ctte; Maintainer for pcmcia-cs is (unknown); Maintainer for tech-ctte is Technical Committee <debian-ctte@lists.debian.org>;

Reported by: Branden Robinson <branden@debian.org>

Date: Wed, 14 Nov 2001 02:18:03 UTC

Severity: serious

Tags: moreinfo, wontfix

Done: Ian Jackson <ian@davenant.greenend.org.uk>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Brian Mays <brian@debian.org>:
Bug#119517; Package pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
New Bug report received and forwarded. Copy sent to Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Tue, 13 Nov 2001 21:09:49 -0500
[Message part 1 (text/plain, inline)]
Package: pcmcia-cs
Version: 3.1.29-3
Severity: serious
Justification: Policy 12.8.1

cardinfo depends on X shared libraries.  Falsifying the package's
dependencies by shifting the shared library dependency on xlibs to a
Suggests isn't good enough.

Please split cardinfo out into a separate package.

To smooth upgrades you could make 2 new packages, say "cardinfo" and
"pcmcia-cardservices" and have pcmcia-cs depend on both of them.

Or you could just have pcmcia-cs Suggest cardinfo and expect people to
install it manually.  How exactly you go about complying with Policy
12.8.1 is up to you.

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux apocalypse 2.4.13 #1 Thu Oct 25 03:13:42 EST 2001 i686
Locale: LANG=C, LC_CTYPE=en_US.iso-8859-1

-- 
G. Branden Robinson                |    I've made up my mind.  Don't try to
Debian GNU/Linux                   |    confuse me with the facts.
branden@deadbeast.net              |    -- Indiana Senator Earl Landgrebe
http://www.deadbeast.net/~branden/ |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Brian Mays <brian@debian.org>:
Bug#119517; Package pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to brian@debian.org (Brian Mays):
Extra info received and forwarded to list. Copy sent to Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #10 received at 119517@bugs.debian.org (full text, mbox):

From: brian@debian.org (Brian Mays)
To: Branden Robinson <branden@debian.org>, 119517@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Wed, 14 Nov 2001 13:20:29 -0500
severity 119517 normal
tags 119517 + wontfix
tags 119517 + moreinfo
thanks

The original bug report states,

> cardinfo depends on X shared libraries.  Falsifying the package's
> dependencies by shifting the shared library dependency on xlibs to a
> Suggests isn't good enough.
>
> Please split cardinfo out into a separate package.

I strongly disagree.  It seems silly to me to create a separate package
for one tiny program that shares the same source tree as the rest of
the pcmcia utilities, will never be installed by itself, and indeed is
worthless without cardmgr, etc. installed.  This type of practice leads
to excessive package fragmentation, which is something that (IMO) Debian
is already suffering from and is a problem that impairs the usability of
the distribution as a whole.

Is pcmcia-cs in violation of Debian policy?  I claim that it is not, and
I shall support this claim with the text of the policy manual itself.

The original bug report cites section 12.8.1 of the "Debian Policy
Manual" as its justification.  The text of this section reads as
follows:

     Programs that can be configured with support for the X Window System
     must be configured to do so and must declare any package dependencies
     necessary to satisfy their runtime requirements when using the X
     Window System.  ...

From this it is clear that cardinfo should be built and its dependencies
must be declared.  I shall address this issue later.  The section also
adds,

                ...  If such a package is of higher priority than the X
     packages on which it depends, it is required that either the
     X-specific components be split into a separate package, or that an
     alternative version of the package, which includes X support, be
     provided, or that the package's priority be lowered.

The pcmcia-cs package has a priority of "extra"; the xlibs package,
which is required by cardinfo to work, has a priority of "standard".
Therefore, this part does not apply.

Section 12.8.1 is not the only part of the policy manual that requires
pcmcia-cs to declare package dependencies for cardinfo.  Section 2.3.4,
on "Dependencies", states,

     Every package must specify the dependency information about other
     packages that are required for the first to work correctly.

     For example, a dependency entry must be provided for any shared
     libraries required by a dynamically-linked executable binary in a
     package.

What exactly does that mean?  What is a "dependency entry", and what
does the policy manual consider to be a dependency?  The closest
thing to a definition that I can find is in section 7, "Declaring
relationships between packages", which says,

     Packages can declare in their control file that they have certain
     relationships to other packages - for example, that they may not be
     installed at the same time as certain other packages, and/or that they
     depend on the presence of others, or that they should overwrite files
     in certain other packages if present.

     This is done using the `Depends', `Pre-Depends', `Recommends',
     `Suggests', `Enhances', `Conflicts', `Provides' and `Replaces' control
     file fields.

The manual further discusses binary dependencies in section 7.2:

     These five fields [i.e., "Depends", "Recommends", "Suggests",
     "Enhances", and "Pre-Depends"] are used to declare a dependency
     relationship by one package on another.  ...

Thus, any level of dependency is sufficient to "declare a dependency
relationship" (i.e., a dependency) on another package.  Now the only
question that remains is which level is appropriate?  The levels of
dependencies are discussed later in section 7.2:

     The meaning of the five dependency fields is as follows:

     `Depends'
          This declares an absolute dependency.  A package will not be
          configured unless all of the packages listed in its `Depends'
          field have been correctly configured.

          The `Depends' field should be used if the depended-on package is
          required for the depending package to provide a significant
          amount of functionality.

          The `Depends' field should also be used if the `postinst',
          `prerm' or `postrm' scripts require the package to be present in
          order to run.  Note, however, that the `postrm' cannot rely on
          any non-essential packages to be present during the `purge'
          phase.

Since cardinfo does not contribute a "significant amount of
functionality" to the package, this is not the appropriate level of
dependency for the packages required to make cardinfo work.  Later in
section 7.2, "Suggests" is discussed:

     `Suggests'
          This is used to declare that one package may be more useful with
          one or more others.  Using this field tells the packaging system
          and the user that the listed packages are related to this one and
          can perhaps enhance its usefulness, but that installing this one
          without them is perfectly reasonable.

Since it is perfectly reasonable to install pcmcia-cs on a system
without X installed, this appears to be the appropriate level of
dependency for the X libraries.  The manual also adds,

     When selecting which level of dependency to use you should consider
     how important the depended-on package is to the functionality of the
     one declaring the dependency.  Some packages are composed of
     components of varying degrees of importance.  Such a package should
     list using `Depends' the package(s) which are required by the more
     important components.  The other components' requirements may be
     mentioned as Suggestions or Recommendations, as appropriate to the
     components' relative importance.

This part clearly states that it is appropriate for packages to be
composed of several components -- thereby, implying that package
fragmentation is not necessary -- and that it is acceptable if some of
the less important components of a package do not work, depending on
how fully the dependencies are satisfied.  Clearly, if the dependencies
are satisfied at all levels -- "Depends", "Recommends", and "Suggests"
-- everything should work.  If the user is willing to sacrifice some
components, however, he or she is free to ignore some of the lesser
dependencies.

In conclusion, cardinfo requires the X libraries to work, and therefore,
a dependency is required.  Since this is a minor component of the
pcmcia-cs package, this requirement is met by the "Suggests" dependency
in the control file.  I find nothing in Debian policy that requires me
to move cardinfo into a separate package, and personally, I think that
splitting a very minor component of a package into its own separate
package is unnecessary and a poor idea, in general.

Unless someone can demonstrate to me that Debian policy explicitly
requires me split the pcmcia-cs package into two packages, I shall
assume that the decision is left to my discretion as package maintainer,
and I will close this bug report.

- Brian



Severity set to `normal'. Request was from brian@debian.org (Brian Mays) to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: wontfix Request was from brian@debian.org (Brian Mays) to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: moreinfo Request was from brian@debian.org (Brian Mays) to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Brian Mays <brian@debian.org>:
Bug#119517; Package pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #21 received at 119517@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 119517@bugs.debian.org, control@bugs.debian.org, debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Wed, 14 Nov 2001 14:23:22 -0500
[Message part 1 (text/plain, inline)]
severity 119517 serious
reassign 119517 tech-ctte,pcmcia-cs
thanks

I am requesting a ruling from the Technical Committee on the meaning of
"dependency" as used in the Policy Manual.

My position is that shared library dependencies as determined by
dpkg-shlibdeps must always be delcared in a package's Pre-Depends or
Depends control data.

Mr. Mays's position is that shared library dependencies may be declared
as "dependency" relationship, which may mean one of two things:
  1) 'Depends', 'Pre-Depends', 'Recommends', 'Suggests', 'Enhances',
     'Conflicts', 'Provides' or 'Replaces'; or
  2) "Depends", "Recommends", "Suggests", "Enhances", or "Pre-Depends"
and that in any event, the selection of which of these relationships is
used should be a matter of the package maintainer's discretion.

I agree with Mr. Mays that the existing Policy Manual is insufficiently
clear on this issue.  Since Policy is now frozen for the woody release,
I am requesting an interpretive ruling from the Technical Committee that
will be binding for the woody release.  The Debian Policy group can, of
course, draft an amendment to the Manual that will be controlling for
subsequent releases.

As support for my position I offer the following arguments:

1) Failure of the runtime linker to load required shared libraries
results in the complete failure of the associated program to run.  No
friendly error message, no help text, zilch.  Traditionally, Debian
users have never had to deal with this sort of error except when there
were very serious problems (bugs) in a package (or when they are dealing
with non-Debian-packaged software).

2) If a part of a package depends on some shared libraries that are not
desirable in all scenarios, the part of the package that does so can and
should be split off.  Package fragmentation proliferation is not an
intrinsic evil; its costs must be weighed against the benefits.  I think
the benefits of dpkg-shlibdeps, when used as intended, are far too great
to ignore.

3) I suggest that it is unreasonable for "Conflicts", "Replaces",
"Provides", or "Enhances", as alternatives to "Depends",  to be
interpreted as a satisfactory usage of a "dependency" relationship when
delcaring an object's shared library dependency.  Perhaps this aspect of
his argument is facetious and he simply wants liberty to downgrade
shared library dependencies to "Recommnds" or "Suggests".

4) I know of no other package in Debian that behaves in this manner.
Every package I know of that has shared library dependencies declares
them as such (or doesn't declare them in the control data at all, which
I think Mr. Mays would agree is a bug).

I invite the Technical Committee to review the bug logs of #119517 for
further arguments for and against my request.

-- 
G. Branden Robinson                |    The errors of great men are
Debian GNU/Linux                   |    venerable because they are more
branden@debian.org                 |    fruitful than the truths of little
http://people.debian.org/~branden/ |    men.         -- Friedrich Nietzsche
[Message part 2 (application/pgp-signature, inline)]

Severity set to `serious'. Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reassigned from package `pcmcia-cs' to `tech-ctte,pcmcia-cs'. Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #30 received at 119517@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: 119517@bugs.debian.org, debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Wed, 14 Nov 2001 15:14:24 -0500
Bug #119517 concerns the bundled little utility called cardinfo.
I quote the maintainer: 

 'Since cardinfo does not contribute a "significant amount of
 functionality" to the package, this is not the appropriate level of
 dependency for the packages required to make cardinfo work.'

Ironically, this same utility was involved in a very similar situation in
December 1998 when it was linked against non-free XForms, and the package
had only a Suggests dependency on non-free/libforms.  Some of us objected
to a dependency on a non-free library for a package in main. Brian argued
exactly the same point at the time, that the utility played only a small
part in the package.

See the debian-devel archives for December 1998 for a thread with subject
line:
 Bug#30739: When a tiny part of a package uses non-free libraries

To the technical committee, if you rule that a package's minor binary's
libraries need not be declared as a Depends (I hope not), then please
address the same question with the added twist that the minor binary may
need a dependency to non-free (which is usually not allowed for a package
in main).  I think this case should definately be forbidden as it's a
slippery slope.  One would then only need to package non-free stuff
together with larger related free software in order to get into main
something that would not be allowed by itself.

Thanks,
-- 
Peter Galbraith



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to brian@debian.org (Brian Mays):
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #35 received at 119517@bugs.debian.org (full text, mbox):

From: brian@debian.org (Brian Mays)
To: 119517@bugs.debian.org, debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Wed, 14 Nov 2001 17:04:01 -0500
Branden Robinson <branden@debian.org> wrote:

> I am requesting a ruling from the Technical Committee on the meaning
> of "dependency" as used in the Policy Manual.

I second this request.

> My position is that shared library dependencies as determined by
> dpkg-shlibdeps must always be delcared in a package's Pre-Depends or
> Depends control data.

I support the alternative position that shared library dependencies
can be satisfied by any of the "Depends", "Recommends", "Suggests", or
"Pre-Depends" fields, according to the importance of the component of
the package that requires the shared library.  I have never suggested
that "Conflicts", "Replaces", "Provides", or "Enhances" can or should be
alternatives to "Depends".  I merely stated in an earlier message that
these are classified in the policy manual as a "dependency relationship"
between two packages

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.

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.

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.

Clearly, the Debian policy currently favors the second approach, as is
evident from the following paragraph from section 7.2 of the policy
manual (please forgive me for quoting this paragraph twice in this bug
report):

     When selecting which level of dependency to use you should consider
     how important the depended-on package is to the functionality of
     the one declaring the dependency.  Some packages are composed of
     components of varying degrees of importance.  Such a package should
     list using `Depends' the package(s) which are required by the more
     important components.  The other components' requirements may be
     mentioned as Suggestions or Recommendations, as appropriate to the
     components' relative importance.

Of course, nowhere does the manual mention which level of dependency
should be used for shared libraries, but as I have argued above, there
should be no difference between a shared library and any other component
that a program would need to use.

I suspect that the paragraph from the policy manual above was written
fairly early in the life of the Debian project, when we were more
concerned with package fragmentation.  (I distinctly recall Ian Jackson
arguing against the unnecessary splitting of packages in 1996.)  I think
that excessive package fragmentation is a serious issue, which should
be addressed.  I find it ridiculous that I must install one package
to get fetchmail and another package to configure it.  In addition to
over-complicating the process of package selection, this splitting of
packages often causes annoying problems during upgrades.  These problems
should not occur if everything is done correctly, but as I have noticed
in the past, this is rarely the case.

Additional comments were provided by Peter S Galbraith
<GalbraithP@dfo-mpo.gc.ca>.  He wrote:

> Ironically, this same utility was involved in a very similar situation
> in December 1998 when it was linked against non-free XForms, and the
> package had only a Suggests dependency on non-free/libforms.  Some
> of us objected to a dependency on a non-free library for a package
> in main. Brian argued exactly the same point at the time, that the
> utility played only a small part in the package.

Has it been that long ago?  Peter Galbraith is correct; I have used this
same argument before.  Since that time, cardinfo no longer uses XForms.

> To the technical committee, if you rule that a package's minor
> binary's libraries need not be declared as a Depends (I hope not),
> then please address the same question with the added twist that the
> minor binary may need a dependency to non-free (which is usually not
> allowed for a package in main).  I think this case should definately
> be forbidden as it's a slippery slope.  One would then only need to
> package non-free stuff together with larger related free software in
> order to get into main something that would not be allowed by itself.

The last sentence is not entirely correct, or at least, is very
misleading.  There is no way that non-free software could be included
in Debian's main distribution.  This is prohibited by policy as it now
stands.  The only possibility that can occur, which was addressed back
in 1998, is that free software (i.e., DFSG free software) that would
have been consigned to contrib could be included in main as a minor
component of a package.  This software, however, cannot constitute a
significant portion of the package and cannot provide a significant
part of the functionality of the package.  I don't see any problem with
this, however.  If an additional free program is installed that requires
non-free stuff and it doesn't work, then where have we compromised our
values?

The opposite view, which has been advocated by RMS, is that free
software and packages of free software should make no mention of
non-free software whatsoever.  IIRC, we have rejected this position in
the past, and still reject it today.

I have a couple of side notes that are not directly related to my
argument:

1) All dependencies should be declared at some level.  That is, if the
dependencies are satisfied at all levels -- "Pre-Depends", "Depends",
"Recommends", and "Suggests" -- nothing should fail due to missing
components.  My position is that if the user is willing to sacrifice
some components, however, he or she should be free to ignore some of
the lower level dependencies.  If shared library dependencies (or other
similar dependencies on data or other programs) are not in the control
data at all, then this is a bug.

2) Use of dpkg-shlibdeps is not limited to dependencies at the "Depends"
level.  It also works with "Recommends" and "Suggests".  In fact, I use
it in the pcmcia-cs package to generate the "Suggests" dependency for
cardinfo.

I agree with Branden Robinson that this issue should be clarified.  I
don't think that there is any one technically correct answer to this
question.  Some resolutions are more consistent than others, however.
In the end, the answer depends on our philosophy of what constitutes a
package and what constitutes a dependency.  I feel that my definitions
are closer to the original meanings of these two terms in the early
days of the Debian project, as reflected by the current wording of
the "Debian Policy Manual".  My only hope is that, in the end, we are
consistent in the way in which we treat this problem.

Sincerely,

- Brian

-- 
Brian Mays
Debian Pcmcia-cs Package Maintainer 



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #40 received at 119517@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 119517@bugs.debian.org, debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Wed, 14 Nov 2001 17:12:29 -0500
[Message part 1 (text/plain, inline)]
On Wed, Nov 14, 2001 at 03:14:24PM -0500, Peter S Galbraith wrote:
> To the technical committee, if you rule that a package's minor binary's
> libraries need not be declared as a Depends (I hope not), then please
> address the same question with the added twist that the minor binary may
> need a dependency to non-free (which is usually not allowed for a package
> in main).  I think this case should definately be forbidden as it's a
> slippery slope.  One would then only need to package non-free stuff
> together with larger related free software in order to get into main
> something that would not be allowed by itself.

I think both should be forbidden.

ELF objects, minor or major, must declare shared library dependencies
as Depends.

ELF objects, minor or major, that link against non-free shared libraries
must not go into main.

-- 
G. Branden Robinson                |      "There is no gravity in space."
Debian GNU/Linux                   |      "Then how could astronauts walk
branden@debian.org                 |       around on the Moon?"
http://people.debian.org/~branden/ |      "Because they wore heavy boots."
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #45 received at 119517@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Branden Robinson <branden@debian.org>, 119517@bugs.debian.org
Cc: debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Thu, 15 Nov 2001 01:05:10 +0000 (GMT)
Branden Robinson writes ("Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package"):
...
> I think both should be forbidden.
> 
> ELF objects, minor or major, must declare shared library dependencies
> as Depends.

This is a silly position.

For example, here is are two alternative suggestions which would make
it reasonable (in the instant case) for cardinfo to link against
libraries only mentioned via Suggest or otherwise:

(a) The pcmcia-cs maintainer could choose to make `cardinfo' be a
script which checked whether the appropriate libraries were present
and otherwise produced a more helpful error message.

(b) The libc maintainer could choose to `improve' the error message
from ld.so so that it was considered suitable for the kinds of users
Branden presumably wants to avoid seeing it.

Both of these would clearly be feature requests.  Furthermore, it
seems to me to be very much a matter of opinion whether these are
better than the current situation.

So in summary, I don't consider the current behaviour (fail with an
appropriate error message, which standard mechanisms would allow the
user to diagnose) sufficiently bad to say it's a bug.

(I assume that the situation is documented in the manpage for
cardinfo or some other appropriate places; if not, I assume the
pcmcia-cs maintainer will agree that it should be.)


Having read what the policy manual has to say, I agree that it's
slightly unclear if you're a bit stubborn.  The section on the
meanings of dependency fields (7.2) is clear, IMO.  But, in 9.3, it
says:

  You will need to place a ${shlib:Depends} variable in the Depends
  field in the control file for this to work.

If you have an axe to grind, you might interpret this to mean that
only a Depends field was allowed.  I think this is a disingenuous
reading, but if people complain perhaps we should fix it.  I suggest
we add a footnote, as follows:

  You will need to place a ${shlib:Depends} variable in the Depends
  field[##] in the control file for this to work.

  [##] Or another appropriate dependency field, such as Recommends or
  Suggests (see section 7.2).

(Of course the Technical Committee does not interpret the policy
manual, though we may specify its contents.  Our judgements about
packages stand on their own.)


> ELF objects, minor or major, that link against non-free shared libraries
> must not go into main.

I don't think this is a technical issue.  Whether we allow a Suggests
dependency out of main into non-free (or indeed any other kind of
reference intended to an administrator or user that non-free software
should be used) is a political question, which the Technical Committee
is not supposed to decide.  I think the Project Leadership should
decide (subject to the oversight in the Constitution).

If the political decision is that references from main to non-free are
prohibited, then clearly a even a Suggests, or an unannounced
dependency, is inappropriate.  Then the program should be in contrib.


What do other members of the Committee think ?


Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #50 received at 119517@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 119517@bugs.debian.org, debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Wed, 14 Nov 2001 20:47:35 -0500
[Message part 1 (text/plain, inline)]
On Thu, Nov 15, 2001 at 01:05:10AM +0000, Ian Jackson wrote:
> (a) The pcmcia-cs maintainer could choose to make `cardinfo' be a
> script which checked whether the appropriate libraries were present
> and otherwise produced a more helpful error message.

That would satisfy me, as long as the package in the meantime also
complies with Policy 12.8.7.

> (I assume that the situation is documented in the manpage for
> cardinfo or some other appropriate places;

Not as far as I know.

>   You will need to place a ${shlib:Depends} variable in the Depends
>   field[##] in the control file for this to work.
> 
>   [##] Or another appropriate dependency field, such as Recommends or
>   Suggests (see section 7.2).

IMO using anything other than Depends should be so strongly discouraged
that we make it a "must", with the understanding that individual
packages can be excepted from particular Policy points, as has always
been recognized.

In part, I simply find it strange to have Xlib-dependent programs
installed on systems that don't even use X, which can be the case with
cardinfo.

> > ELF objects, minor or major, that link against non-free shared libraries
> > must not go into main.
> 
> I don't think this is a technical issue.

This was my response to Peter Galbraith and I personally don't care
whether the Technical Committee rules on it or not.  It doesn't appear
to a be point at issue.

-- 
G. Branden Robinson                |    You should try building some of the
Debian GNU/Linux                   |    stuff in main that is
branden@debian.org                 |    modern...turning on -Wall is like
http://people.debian.org/~branden/ |    turning on the pain. -- James Troup
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Dale Scheetz <dwarf@polaris.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #55 received at 119517@bugs.debian.org (full text, mbox):

From: Dale Scheetz <dwarf@polaris.net>
To: Ian Jackson <ian@davenant.greenend.org.uk>, <119517@bugs.debian.org>
Cc: debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Thu, 15 Nov 2001 09:10:26 -0500 (EST)
On Thu, 15 Nov 2001, Ian Jackson wrote:

> Branden Robinson writes ("Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package"):
> ...
> > I think both should be forbidden.
> >
> > ELF objects, minor or major, must declare shared library dependencies
> > as Depends.
>
> This is a silly position.

Doesn't seem that way to me. Looks logical and consistant.

The current situation seems to leave the package maintainer to decide the
level of importance of a particular component. While this fits with our
principles of maintainer autonomy, this particular situation allows ugly
surprises for the end user. Reduction of such surprise _is_ the
responsibility of a distribution.

As an example, consider the atari800 package that I maintain. Suppose that
I convinced the upstream to include an interface using xforms, or some
other non-free library. By the current standard I can consider this
component to have trivial concequences for the package and not include the
dependence upon xforms. (The binary element only comprises 20% of the
executable functionality of the package)

The user who expects that element to function is going to be less than
satisfied by my solution.

I would argue: "If the element provides a function that can be considered
a useful feature of the package, then shared libraries must be declared on
the Depends (or PreDepends) field."

cardmanager satisfies the above criterion and should have a Depends entry
for its shared libraries, and should go in contrib.

On the non-free component of this problem, I'd like to open a real can of
worms. The LGPL was designed to allow non-free programs to use a free
library. Linking against the LGPL doesn't cause the binary to become free.
It might be argued that there is no logical reason that the converse
should convey non-freedom on the linking program.

Don't get me wrong. I'm not in favor of free code linking to non-free
libs, I'm just trying to resolve the logic.

Waiting is,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-                                                                    _-
_- aka   Dale Scheetz                   Phone:   1 (850) 656-9769     _-
_-       Flexible Software              11000 McCrackin Road          _-
_-       e-mail:  dwarf@polaris.net     Tallahassee, FL  32308        _-
_-                                                                    _-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
              available at: http://www.polaris.net/~dwarf/




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #60 received at 119517@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Dale Scheetz <dwarf@polaris.net>
Cc: <119517@bugs.debian.org>, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Thu, 15 Nov 2001 15:17:00 +0000 (GMT)
Dale Scheetz writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s  eparate package"):
...
> The current situation seems to leave the package maintainer to decide the
> level of importance of a particular component. While this fits with our
> principles of maintainer autonomy, this particular situation allows ugly
> surprises for the end user. Reduction of such surprise _is_ the
> responsibility of a distribution.

Please, not the old `least surprise' chestnut.  That can be used to
justify anything.

> As an example, consider the atari800 package that I maintain. Suppose that
> I convinced the upstream to include an interface using xforms, or some
> other non-free library. By the current standard I can consider this
> component to have trivial concequences for the package and not include the
> dependence upon xforms. (The binary element only comprises 20% of the
> executable functionality of the package)

I think the non-freeness you're introducing muddies the waters.
I shall consider for the moment only the question with a free library.

I don't think anyone is suggesting that a complete lack of any
dependency will often be appropriate (though it seems to me that it
might be, rarely).  But this is a far cry from always requiring
Depends.  Why would a Suggests or Recommends not be appropriate ?

> The user who expects that element to function is going to be less than
> satisfied by my solution.

Surely the question here is whether most users *would* expect that
element to be there and not know what to do about it if it was
missing.  Whether this is true depends on the particular package and
the situation at hand.  Also, of course, if a Recommends or Suggests
was used, the user's package selection and installation tools will (or
should!) have informed them about the other package, and the package
description can explain what does and doesn't work without the extra
parts.

Requiring Depends forces all users who install the using package to
install also the used one, or forces the maintainer to split up the
binary package into many pieces.  It is a statement that we think it
is (nearly) never reasonable to install one thing without the other -
and that's just not true in this case.

When a question depends on the particular package, and the other
circumstances at hand, policy documents should not dictate a
particular choice (though they may issue advice).


> I would argue: "If the element provides a function that can be considered
> a useful feature of the package, then shared libraries must be declared on
> the Depends (or PreDepends) field."

What's special about shared libraries ?  I don't see how a requirement
for a shared library differs from any other kind of dependency (eg,
calling a program that might not be installed).  Are you suggesting
that all kinds of run-time dependencies should be Depends ?  That
would amount to abolishing Recommends and Suggests !

> cardmanager satisfies the above criterion and should have a Depends entry
> for its shared libraries, and should go in contrib.

You are confused, surely ?  We were talking about cardinfo's
dependency on X, not cardmanager or any non-free libraries.


> On the non-free component of this problem, I'd like to open a real can of
> worms. The LGPL was designed to allow non-free programs to use a free
> library. Linking against the LGPL doesn't cause the binary to become free.
> It might be argued that there is no logical reason that the converse
> should convey non-freedom on the linking program.
> 
> Don't get me wrong. I'm not in favor of free code linking to non-free
> libs, I'm just trying to resolve the logic.

The question is not whether the resulting program is Free (or
DFSG-Free or whatever).  The questions are, does it go in main and
what does its control file look like ?  We can't answer the question
of what goes in main (except perhaps in some obscure cases, or if
someone specifically delegates the decision to us).  That is a
political question.  We can answer the question about the control
file, but that requires an answer to the political question first.
Nor should we (the Technical Committee) make a decision on legal
questions.

So I suggest that we decline to comment on the situation with non-free
libraries, except to suggest that the Project Leadership should
arrange for the situation to be formally clarified (eg, by directing
an appropriate change to the website or policy documents).


Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to <adconrad@0c3.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #65 received at 119517@bugs.debian.org (full text, mbox):

From: "Adam Conrad" <adconrad@0c3.net>
To: <119517@bugs.debian.org>
Cc: <debian-ctte@lists.debian.org>
Subject: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Thu, 15 Nov 2001 08:55:05 -0700
I'm going to lend my two cents here and agree with the people who think
that "Suggests" is good enough for this particular dependency.

If we believe that "installation of a package must require that all
functionality of said package functions after installation" we have a
LOT of packages that don't conform to this ideal.

Example 1:

kernel-source-x.x.x packages:

Without libncurses5-dev, "make menuconfig" doesn't work.
Without tcl/tk, "make xconfig" doesn't work.

Should the kernel source depend on a devel package that many people
don't need, as well as a full functional X11 system with tcl/tk?  If it
doesn't, "functionality" will be lost, and people will have to fall back
to "make config", which many find confusing.  Should we patch the
makefile to bomb gracefully when missing the packages it needs, and tell
us exactly what package needs to be installed?... Maybe.  Should we
depend on all of those packages?... Certainly not.

Example 2:

The konqueror web/file browser:

Without "kdelibs3-crypto" installed, konqueror won't do SSL.  In today's
world, SSL web pages are nearly a MUST for a web browser, so does this
mean we have lost "expected functionality", and konqueror should depend
on the crypto support, and move to non-US?  Or should we perhaps have
two completely separate builds of ANY KDE application that has SSL
support, {app|app-ssl}, nearly doubling KDE's size in the archive, so
that users will know immediately to install "the Konqueror that handles
SSL"?  Obviously, both of these solutions appear to be ludicrous, and
the better solution is what's already in place.  A dialog box that pops
up telling you that "SSL won't work until you install package X".

Of course, the konqueror example becomes moot, now that we are finally
clearing up the crypto-in-main issues, but that's beside the point.  If
we hadn't cleared up those issues, konqueror would be in exactly the
same boat as pcmcia-cs, and frankly, I think they both do The Right
Thing.  Both of them provide dependencies to make the majority of the
functionality go, and recommends or suggests to round out the rest.

About the only thing that would be a nice change would be, as was
previously mentioned, a simple wrapper around the 'cardinfo' binary that
will inform us to install the 'xlibs' package, so if we try to run it,
we don't get frustrated that it doesn't work.

Just my two (or twelve, this turned out longer than I'd intended) bits.

... Adam Conrad




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Dale Scheetz <dwarf@polaris.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #70 received at 119517@bugs.debian.org (full text, mbox):

From: Dale Scheetz <dwarf@polaris.net>
To: Ian Jackson <ian@davenant.greenend.org.uk>
Cc: 119517@bugs.debian.org, <debian-ctte@lists.debian.org>
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Thu, 15 Nov 2001 14:31:21 -0500 (EST)
On Thu, 15 Nov 2001, Ian Jackson wrote:

> Dale Scheetz writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s  eparate package"):
> ...
> > The current situation seems to leave the package maintainer to decide the
> > level of importance of a particular component. While this fits with our
> > principles of maintainer autonomy, this particular situation allows ugly
> > surprises for the end user. Reduction of such surprise _is_ the
> > responsibility of a distribution.
>
> Please, not the old `least surprise' chestnut.  That can be used to
> justify anything.

So, you believe that it is OK for the distribution to deliver packages in
a state that they do not work properly?

The surprise is: I installed the package. Dpkg said all necessary
dependencies were satisfied. I tried to run the program, and it failed to
execute because of an unmet library dependency.

You seem to be implying that this is just fine, and I'm an idiot for not
researching the problem and figuring out what I needed to install. To me
this fails to use standard features of the installer and is broken
behavior.

>
> > As an example, consider the atari800 package that I maintain. Suppose that
> > I convinced the upstream to include an interface using xforms, or some
> > other non-free library. By the current standard I can consider this
> > component to have trivial concequences for the package and not include the
> > dependence upon xforms. (The binary element only comprises 20% of the
> > executable functionality of the package)
>
> I think the non-freeness you're introducing muddies the waters.

Aren't we talking about a program element that depends upon a non-free
library?

> I shall consider for the moment only the question with a free library.

But that fails to deal with the issue at hand.

The problem is that the current situation allows a developer to hide a
dependence by making it less than absolute by using Suggests. Even though
the dependency is not declared it still exists. This is a failure to tell
the truth about the package, and not very useful.

>
> I don't think anyone is suggesting that a complete lack of any
> dependency will often be appropriate (though it seems to me that it
> might be, rarely).  But this is a far cry from always requiring
> Depends.  Why would a Suggests or Recommends not be appropriate ?
>
Because the package manager doesn't even indicate when a Suggests or
Recomments is present. While dselect actually does bring this to the
attention of the user, apt-get doesn't and neither does dpkg when used
stand-alone.

The element of the package will not run without the library, so it must be
declared as a Depends. If the binary element serves no useful purpose for
the package, then why is it even included?

> > The user who expects that element to function is going to be less than
> > satisfied by my solution.
>
> Surely the question here is whether most users *would* expect that
> element to be there and not know what to do about it if it was

The element _is_ there, and available for execution, but it doesn't have
the libraries that it needs installed because a _real_ dependency was
undeclared! In the case of the atari800 package, each different interface
is accessible using the simply atari800 call. The script desides which
element to run based on conditions it finds at execution time.

WRT cardmanager, isn't this element called by some other element in the
package? Doesn't it have some expected functionality that the user
expects? Seems so to me...

> missing.  Whether this is true depends on the particular package and
> the situation at hand.  Also, of course, if a Recommends or Suggests
> was used, the user's package selection and installation tools will (or
> should!) have informed them about the other package, and the package
> description can explain what does and doesn't work without the extra
> parts.
>
As I pointed out previously only dselect does any of this. In any case,
there are no directives that require the maintainer to do these things if
a dependent element is only suggested. In fact, that is the current case
under discussion.

> Requiring Depends forces all users who install the using package to
> install also the used one, or forces the maintainer to split up the
> binary package into many pieces.  It is a statement that we think it
> is (nearly) never reasonable to install one thing without the other -
> and that's just not true in this case.
>
If that is indeed the case, and I don't think it is here, then the element
involved should go into an extra package.

> When a question depends on the particular package, and the other
> circumstances at hand, policy documents should not dictate a
> particular choice (though they may issue advice).

I can't make anything out of this statement except that you don't think
policy should dictate the use of depends. On this we disagree.

>
>
> > I would argue: "If the element provides a function that can be considered
> > a useful feature of the package, then shared libraries must be declared on
> > the Depends (or PreDepends) field."
>
> What's special about shared libraries ?  I don't see how a requirement

The binaries linked to them will not execute without them. In the other
situation where a program may call a binary from a different package the
binary in question runs just fine, but may fail to perform the function
desired if the dependent package is not installed.

In the first case the program is totally unusable. In the second case the
program works fine with the exception of the special functionality
provided by the depended package.

> for a shared library differs from any other kind of dependency (eg,
> calling a program that might not be installed).  Are you suggesting
> that all kinds of run-time dependencies should be Depends ?  That
> would amount to abolishing Recommends and Suggests !

Not at all! If you want printing capability you install the recommended
package. If you don't need to print the output of the program, then it
will work just fine without that element.

The only runtime dependency that I can fathom is, in fact, shared
libraries. Is there anything else that can cause the binary to fail to
run? (I understand that I can code up something that fails to run under
other conditions, but I don't think that special case is of much use in
real practices. Normally the desire is to begin execution and then ask
what the user wants to do.)

>
> > cardmanager satisfies the above criterion and should have a Depends entry
> > for its shared libraries, and should go in contrib.
>
> You are confused, surely ?  We were talking about cardinfo's
> dependency on X, not cardmanager or any non-free libraries.

The freedom or lack thereof is not the issue. The functionality of the
program is what is at issue. Does cardinfo work without the X libraries
installed? If it doesn't then the package is broken.

>
>
> > On the non-free component of this problem, I'd like to open a real can of
> > worms. The LGPL was designed to allow non-free programs to use a free
> > library. Linking against the LGPL doesn't cause the binary to become free.
> > It might be argued that there is no logical reason that the converse
> > should convey non-freedom on the linking program.
> >
> > Don't get me wrong. I'm not in favor of free code linking to non-free
> > libs, I'm just trying to resolve the logic.
>
> The question is not whether the resulting program is Free (or
> DFSG-Free or whatever).  The questions are, does it go in main and
> what does its control file look like ?  We can't answer the question
> of what goes in main (except perhaps in some obscure cases, or if

I beg your pardon. What goes in main is very well defined.

> someone specifically delegates the decision to us).  That is a
> political question.  We can answer the question about the control
> file, but that requires an answer to the political question first.
> Nor should we (the Technical Committee) make a decision on legal
> questions.
>
> So I suggest that we decline to comment on the situation with non-free
> libraries, except to suggest that the Project Leadership should
> arrange for the situation to be formally clarified (eg, by directing
> an appropriate change to the website or policy documents).
>
I understand that you are trying to answer my COW question, but I don't
see any answer here. The non-free issue is clearly declared. Packages that
depend upon non-free elements go into contrib unless they are under a
non-free license.

Whether we are talking about a non-free element/library or a free one, the
issue here is how does this impact the functionality of the delivered
package.

My suggestion was that under the current situation, a maintainer can
simply fail to report the dependence and the package can go into main.
This is counter to the very reason for the depends existance.

My point is that whether the element is in main or in non-free, the
dependence must be declared.

With respect to cardinfo, isn't it used by the installation process? Is it
working correctly under those conditions? Are the suggested elements
installed and used? If it is managed correctly during the install, then it
should end up in a working state afterwards, right?

If I can use the package effectively without this element, then I withdraw
my demand that it be declared. It was my understanding that this element
is commonly used and is an expected element of this package. If that is
true, then its needs must be declared.

Luck,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-                                                                    _-
_- aka   Dale Scheetz                   Phone:   1 (850) 656-9769     _-
_-       Flexible Software              11000 McCrackin Road          _-
_-       e-mail:  dwarf@polaris.net     Tallahassee, FL  32308        _-
_-                                                                    _-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
              available at: http://www.polaris.net/~dwarf/




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to brian@debian.org (Brian Mays):
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #75 received at 119517@bugs.debian.org (full text, mbox):

From: brian@debian.org (Brian Mays)
To: Dale Scheetz <dwarf@polaris.net>
Cc: debian-ctte@lists.debian.org, 119517@bugs.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Thu, 15 Nov 2001 16:49:41 -0500
Dale Scheetz <dwarf@polaris.net> wrote:

> With respect to cardinfo, isn't it used by the installation
> process? Is it working correctly under those conditions? Are the
> suggested elements installed and used? If it is managed correctly
> during the install, then it should end up in a working state
> afterwards, right?
>
> If I can use the package effectively without this element, then I
> withdraw my demand that it be declared. It was my understanding that
> this element is commonly used and is an expected element of this
> package. If that is true, then its needs must be declared.

I'm afraid you have misunderstood what is being discussed.  This
discussion is about cardinfo, an X utility for monitoring and
controlling the PCMCIA card slots.  It is a minor part of the package
that can easily be ignored.  In fact, I myself never use it, except to
test the program itself.

This program *used to* depend on a non-free library, but that was years
ago.  Today it uses only the standard C and X libraries.

If the user looks up the documentation on cardinfo, he finds

    $ apropos cardinfo
    cardinfo (1) - PCMCIA card monitor and control utility for X

It is clearly documented that it is an X program, therefore requiring X
to be running (and of course, xlibs to be installed).  It even resides
under the /usr/X11R6 directory, but that is something that will need to
be changed to comply with current policy (it's on my todo list for the
next release).  I'll admit that it would help if the package description
mentioned that xlibs are required for cardinfo, but that is something
that can be easily fixed and does not affect the main point being
discussed here.

If xlibs are not present, the package is not broken.  The package
provides PCMCIA support, which is provided even if cardinfo cannot be
run.

The original bug report that started this discussion stated that
cardinfo must be split into its own package to satisfy Debian policy.
I don't interpret the current policy that way, which is why a decision
from the technical committee was requested.  The larger issue is whether
dependence on shared libraries automatically implies a dependency level
of "Depends" for the package.

- Brian



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Dale Scheetz <dwarf@polaris.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #80 received at 119517@bugs.debian.org (full text, mbox):

From: Dale Scheetz <dwarf@polaris.net>
To: Brian Mays <brian@debian.org>
Cc: debian-ctte@lists.debian.org, <119517@bugs.debian.org>
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Thu, 15 Nov 2001 17:54:14 -0500 (EST)
On Thu, 15 Nov 2001, Brian Mays wrote:

> Dale Scheetz <dwarf@polaris.net> wrote:
>
> > With respect to cardinfo, isn't it used by the installation
> > process? Is it working correctly under those conditions? Are the
> > suggested elements installed and used? If it is managed correctly
> > during the install, then it should end up in a working state
> > afterwards, right?
> >
> > If I can use the package effectively without this element, then I
> > withdraw my demand that it be declared. It was my understanding that
> > this element is commonly used and is an expected element of this
> > package. If that is true, then its needs must be declared.
>
> I'm afraid you have misunderstood what is being discussed.  This
> discussion is about cardinfo, an X utility for monitoring and
> controlling the PCMCIA card slots.

No, I understand that just fine

> It is a minor part of the package
> that can easily be ignored.  In fact, I myself never use it, except to
> test the program itself.

The fact that you don't use it doesn't make it minor. The question is: Is
it possible that a user might want to use it.

If there isn't, then don't deliver it.

If there is, then policy is quite clear. Split it off with proper depends.

>
> This program *used to* depend on a non-free library, but that was years
> ago.  Today it uses only the standard C and X libraries.

Understood. The only reason I mentioned non-free in this discussion is
that, if we accept your position, this becomes a loophole that lets
contrib packages into main.
>
> If the user looks up the documentation on cardinfo, he finds
>
>     $ apropos cardinfo
>     cardinfo (1) - PCMCIA card monitor and control utility for X
>
> It is clearly documented that it is an X program, therefore requiring X
> to be running (and of course, xlibs to be installed).  It even resides
> under the /usr/X11R6 directory, but that is something that will need to
> be changed to comply with current policy (it's on my todo list for the
> next release).  I'll admit that it would help if the package description
> mentioned that xlibs are required for cardinfo, but that is something
> that can be easily fixed and does not affect the main point being
> discussed here.
>
> If xlibs are not present, the package is not broken.  The package
> provides PCMCIA support, which is provided even if cardinfo cannot be
> run.

So your position is that cardinfo is of little or no use to those who use
pcmcia? That point isn't clear to me. You think so, others don't. It is
just this sort of undetermined behavior that we are here to clean up.

>
> The original bug report that started this discussion stated that
> cardinfo must be split into its own package to satisfy Debian policy.

Which is quite clear and unambiguous.

> I don't interpret the current policy that way, which is why a decision
> from the technical committee was requested.

If this is the only reason you want us to hear this, then I would suggest
that Policy is correct. End of story.

> The larger issue is whether
> dependence on shared libraries automatically implies a dependency level
> of "Depends" for the package.

No, the issue is "does an element of the package which depends upon a
shared library for any operation at all, require a depends for that shared
library.

You seem to argue that components you don't use don't need depends. This
ignores the reason for a package all together. Your needs are not what is
being satisfied by your package. It is the needs of the rest of the
population that should be of interest here.

Personally, I feel that packages that deliver function should deliver that
function in a working state.

If cardinfo is not needed by the pcmcia packages, but is of some use to
users, then policy already declares the proper proceedure. Split it off.

Luck,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-                                                                    _-
_- aka   Dale Scheetz                   Phone:   1 (850) 656-9769     _-
_-       Flexible Software              11000 McCrackin Road          _-
_-       e-mail:  dwarf@polaris.net     Tallahassee, FL  32308        _-
_-                                                                    _-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
              available at: http://www.polaris.net/~dwarf/




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to brian@debian.org (Brian Mays):
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #85 received at 119517@bugs.debian.org (full text, mbox):

From: brian@debian.org (Brian Mays)
To: Dale Scheetz <dwarf@polaris.net>
Cc: debian-ctte@lists.debian.org, 119517@bugs.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Fri, 16 Nov 2001 11:24:06 -0500
Earlier in this thread, I (Brian Mays) wrote:

> > The original bug report that started this discussion stated that
> > cardinfo must be split into its own package to satisfy Debian
> > policy.
> >
> > [...]
> >
> > I don't interpret the current policy that way, which is why a
> > decision from the technical committee was requested.

Dale Scheetz <dwarf@polaris.net> replied:

> If this is the only reason you want us to hear this, then I would
> suggest that Policy is correct. End of story.

I did not bring this to the attention of the committee; Branden
Robinson did.  I believe that the current Policy is correct and that my
interpretation of this policy is correct.  Read my original response to
this bug report.  I have yet to see anyone point to a specific part of
the text of the policy manual that states that cardinfo must be split
into its own package.  I have quoted several sections of the policy
manual that support my claim that it does not.

> > The larger issue is whether dependence on shared libraries
> > automatically implies a dependency level of "Depends" for the
> > package.
>
> No, the issue is "does an element of the package which depends upon a
> shared library for any operation at all, require a depends for that
> shared library.

Yes.  This is exactly what I said or, at least, meant to say.  Perhaps I
was unclear.

> So your position is that cardinfo is of little or no use to those
> who use pcmcia? That point isn't clear to me. You think so, others
> don't. It is just this sort of undetermined behavior that we are here
> to clean up.
>
> [...]
>
> You seem to argue that components you don't use don't need
> depends. This ignores the reason for a package all together. Your
> needs are not what is being satisfied by your package. It is the needs
> of the rest of the population that should be of interest here.

No.  This has nothing to do with me or my needs.  I am involved only in
that I am responsible for reading and understanding Debian policy and
working to make the package I maintain conform to this policy.

Read section 7.2 of the policy manual, particularly the last paragraph.
(I refuse to quote the same paragraph three times in one bug report.)
It unambiguously states that the requirements for part of a package
("other components" to quote the term used by the manual) do not
need to be included in the "Depends" field, but may be placed in the
"Recommends" or "Suggests" fields, as appropriate.  The rules for
determining what is appropriate for each level is given earlier in this
section.

I fail to see the difference between a shared library or any other
"requirement" of a component.  Either something is required or it
is not.  Either something will work, because everything it needs is
available, or it will not.

> The fact that you don't use it doesn't make it minor. The question
> is: Is it possible that a user might want to use it.
>
> If there isn't, then don't deliver it.
>
> If there is, then policy is quite clear. Split it off with proper
> depends.
>
> [...]
>
> Personally, I feel that packages that deliver function should deliver
> that function in a working state.
>
> If cardinfo is not needed by the pcmcia packages, but is of some use
> to users, then policy already declares the proper proceedure. Split it
> off.

Please tell me where policy declares this.  Cite a section.  Give me a
quote.  I have yet to find this clear declaration that you speak of.
That is all that I was asking for in my original response to this bug
report.  Nobody has yet provided any answer to my request, let alone a
satisfactory one.  You have given me only your personal feelings and
opinions.  While they are useful and I appreciate that you have shared
them, please do not claim that they are official policy.

- Brian



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Dale Scheetz <dwarf@polaris.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #90 received at 119517@bugs.debian.org (full text, mbox):

From: Dale Scheetz <dwarf@polaris.net>
To: Brian Mays <brian@debian.org>
Cc: debian-ctte@lists.debian.org, <119517@bugs.debian.org>
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Fri, 16 Nov 2001 15:55:51 -0500 (EST)
On Fri, 16 Nov 2001, Brian Mays wrote:

> Earlier in this thread, I (Brian Mays) wrote:
>
> Dale Scheetz <dwarf@polaris.net> replied:
>
> > If cardinfo is not needed by the pcmcia packages, but is of some use
> > to users, then policy already declares the proper proceedure. Split it
> > off.
>
> Please tell me where policy declares this.  Cite a section.  Give me a
> quote.  I have yet to find this clear declaration that you speak of.
> That is all that I was asking for in my original response to this bug
> report.  Nobody has yet provided any answer to my request, let alone a
> satisfactory one.  You have given me only your personal feelings and
> opinions.  While they are useful and I appreciate that you have shared
> them, please do not claim that they are official policy.

Straight cut and paste from the web page:

<h3>
<a name="s12.8.1">12.8.1 Providing X support and package priorities</a>
</h3>

<p>
Programs that can be configured with support for the X Window System must
be
configured to do so and must declare any package dependencies necessary to
satisfy their runtime requirements when using the X Window System.  If
such a
package is of higher priority than the X packages on which it depends, it
is
required that either the X-specific components be split into a separate
package, or that an alternative version of the package, which includes X
support, be provided, or that the package's priority be lowered.
</p>

The first sentance is quite clear, isn't it?

Reguarding levels of dependency, the reason shared libraries are more
important than, say, printer support with lpr, is that in the first case
the program doesn't run at all. In the second case, the program will run,
and all but "print page" functionality will be present.

If printing isn't critical to using the tool, i.e. you can create file
output that can be printed via some other means, then the lpr package
isn't critical to the major functionality of the program and a Suggests or
Recommends is adequate.

In your case the cardinfo program will not execute at all without the
shared libraries it needs for X. Thus a Depends is required.

In any case, sentance 1 of 12.8.1 is quite clear on this issue.

Luck,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-                                                                    _-
_- aka   Dale Scheetz                   Phone:   1 (850) 656-9769     _-
_-       Flexible Software              11000 McCrackin Road          _-
_-       e-mail:  dwarf@polaris.net     Tallahassee, FL  32308        _-
_-                                                                    _-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
              available at: http://www.polaris.net/~dwarf/




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to brian@debian.org (Brian Mays):
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #95 received at 119517@bugs.debian.org (full text, mbox):

From: brian@debian.org (Brian Mays)
To: Dale Scheetz <dwarf@polaris.net>
Cc: debian-ctte@lists.debian.org, 119517@bugs.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Fri, 16 Nov 2001 16:54:33 -0500
Dale Scheetz <dwarf@polaris.net> wrote:

> Straight cut and paste from the web page:

> 12.8.1 Providing X support and package priorities ...

I am forwarding my original response to this bug report, since your
reply suggests that you have not read it.  At least, you would not be
requoting section 12.8.1 if you had, since I have already addressed
and discussed everything in that section.  If you want to counter by
returning to the text of this section, you should address my comments or
you should introduce something new to the discussion.

If you have read my response, then forgive me for forwarding it again.
Please, however, do me a favor and reread it.

I have two points for you to consider.  (1) Nowhere is "component"
defined as merely a minor functionality of a program (as in your example
of printer support).  Indeed, since a package is usually comprised of
many files and programs, any reasonable person would conclude that
"component" can refer to one executable out of many in a package.  (2)
Nowhere does the policy manual restrict the term "dependency" to mean
exclusively a "Depends" level dependency.  Instead, it goes out of its
way on several occasions to indicate when it is referring to "Depends".

- Brian

------- Forwarded Message

To: Branden Robinson <branden@debian.org>, 119517@bugs.debian.org
Cc: control@bugs.debian.org
In-Reply-To: Your message of "Tue, 13 Nov 2001 21:09:49 EST."
             <20011113210949.A18162@deadbeast.net> 
References: <20011113210949.A18162@deadbeast.net> 
Date: Wed, 14 Nov 2001 13:20:29 -0500
Message-Id: <20011114182030.EC5FFDF6C@ariel.local.net>

severity 119517 normal
tags 119517 + wontfix
tags 119517 + moreinfo
thanks

The original bug report states,

> cardinfo depends on X shared libraries.  Falsifying the package's
> dependencies by shifting the shared library dependency on xlibs to a
> Suggests isn't good enough.
>
> Please split cardinfo out into a separate package.

I strongly disagree.  It seems silly to me to create a separate package
for one tiny program that shares the same source tree as the rest of
the pcmcia utilities, will never be installed by itself, and indeed is
worthless without cardmgr, etc. installed.  This type of practice leads
to excessive package fragmentation, which is something that (IMO) Debian
is already suffering from and is a problem that impairs the usability of
the distribution as a whole.

Is pcmcia-cs in violation of Debian policy?  I claim that it is not, and
I shall support this claim with the text of the policy manual itself.

The original bug report cites section 12.8.1 of the "Debian Policy
Manual" as its justification.  The text of this section reads as
follows:

     Programs that can be configured with support for the X Window System
     must be configured to do so and must declare any package dependencies
     necessary to satisfy their runtime requirements when using the X
     Window System.  ...

>From this it is clear that cardinfo should be built and its dependencies
must be declared.  I shall address this issue later.  The section also
adds,

                ...  If such a package is of higher priority than the X
     packages on which it depends, it is required that either the
     X-specific components be split into a separate package, or that an
     alternative version of the package, which includes X support, be
     provided, or that the package's priority be lowered.

The pcmcia-cs package has a priority of "extra"; the xlibs package,
which is required by cardinfo to work, has a priority of "standard".
Therefore, this part does not apply.

Section 12.8.1 is not the only part of the policy manual that requires
pcmcia-cs to declare package dependencies for cardinfo.  Section 2.3.4,
on "Dependencies", states,

     Every package must specify the dependency information about other
     packages that are required for the first to work correctly.

     For example, a dependency entry must be provided for any shared
     libraries required by a dynamically-linked executable binary in a
     package.

What exactly does that mean?  What is a "dependency entry", and what
does the policy manual consider to be a dependency?  The closest
thing to a definition that I can find is in section 7, "Declaring
relationships between packages", which says,

     Packages can declare in their control file that they have certain
     relationships to other packages - for example, that they may not be
     installed at the same time as certain other packages, and/or that they
     depend on the presence of others, or that they should overwrite files
     in certain other packages if present.

     This is done using the `Depends', `Pre-Depends', `Recommends',
     `Suggests', `Enhances', `Conflicts', `Provides' and `Replaces' control
     file fields.

The manual further discusses binary dependencies in section 7.2:

     These five fields [i.e., "Depends", "Recommends", "Suggests",
     "Enhances", and "Pre-Depends"] are used to declare a dependency
     relationship by one package on another.  ...

Thus, any level of dependency is sufficient to "declare a dependency
relationship" (i.e., a dependency) on another package.  Now the only
question that remains is which level is appropriate?  The levels of
dependencies are discussed later in section 7.2:

     The meaning of the five dependency fields is as follows:

     `Depends'
          This declares an absolute dependency.  A package will not be
          configured unless all of the packages listed in its `Depends'
          field have been correctly configured.

          The `Depends' field should be used if the depended-on package is
          required for the depending package to provide a significant
          amount of functionality.

          The `Depends' field should also be used if the `postinst',
          `prerm' or `postrm' scripts require the package to be present in
          order to run.  Note, however, that the `postrm' cannot rely on
          any non-essential packages to be present during the `purge'
          phase.

Since cardinfo does not contribute a "significant amount of
functionality" to the package, this is not the appropriate level of
dependency for the packages required to make cardinfo work.  Later in
section 7.2, "Suggests" is discussed:

     `Suggests'
          This is used to declare that one package may be more useful with
          one or more others.  Using this field tells the packaging system
          and the user that the listed packages are related to this one and
          can perhaps enhance its usefulness, but that installing this one
          without them is perfectly reasonable.

Since it is perfectly reasonable to install pcmcia-cs on a system
without X installed, this appears to be the appropriate level of
dependency for the X libraries.  The manual also adds,

     When selecting which level of dependency to use you should consider
     how important the depended-on package is to the functionality of the
     one declaring the dependency.  Some packages are composed of
     components of varying degrees of importance.  Such a package should
     list using `Depends' the package(s) which are required by the more
     important components.  The other components' requirements may be
     mentioned as Suggestions or Recommendations, as appropriate to the
     components' relative importance.

This part clearly states that it is appropriate for packages to be
composed of several components -- thereby, implying that package
fragmentation is not necessary -- and that it is acceptable if some of
the less important components of a package do not work, depending on
how fully the dependencies are satisfied.  Clearly, if the dependencies
are satisfied at all levels -- "Depends", "Recommends", and "Suggests"
- -- everything should work.  If the user is willing to sacrifice some
components, however, he or she is free to ignore some of the lesser
dependencies.

In conclusion, cardinfo requires the X libraries to work, and therefore,
a dependency is required.  Since this is a minor component of the
pcmcia-cs package, this requirement is met by the "Suggests" dependency
in the control file.  I find nothing in Debian policy that requires me
to move cardinfo into a separate package, and personally, I think that
splitting a very minor component of a package into its own separate
package is unnecessary and a poor idea, in general.

Unless someone can demonstrate to me that Debian policy explicitly
requires me split the pcmcia-cs package into two packages, I shall
assume that the decision is left to my discretion as package maintainer,
and I will close this bug report.

- - Brian

------- End of Forwarded Message




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #100 received at 119517@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: debian-policy@lists.debian.org
Cc: 119517@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sat, 17 Nov 2001 00:24:20 -0500
Branden Robinson wrote:
> I think both should be forbidden.
> 
> ELF objects, minor or major, must declare shared library dependencies
> as Depends.
> 
> ELF objects, minor or major, that link against non-free shared libraries
> must not go into main.

Why are ELF objects so special? If we have a rule like this, why should
it not apply to other forms of binaries, or to programs written in
interpreted languages? Perl and python programs can produce ghastly
errors if a library they require is not installed.

Also, I'd hope that a perl or python program that requires a library from
non-free to work has no more business in main than does a ELF executable
with similar requirements.

-- 
see shy jo



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@azure.humbug.org.au>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #105 received at 119517@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: debian-policy@lists.debian.org, debian-ctte@lists.debian.org
Cc: 119517@bugs.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sat, 17 Nov 2001 18:01:09 +1000
[Message part 1 (text/plain, inline)]
On Sat, Nov 17, 2001 at 12:24:20AM -0500, Joey Hess wrote:
> Branden Robinson wrote:
> > I think both should be forbidden.
> > ELF objects, minor or major, must declare shared library dependencies
> > as Depends.
> > ELF objects, minor or major, that link against non-free shared libraries
> > must not go into main.
> Why are ELF objects so special? 

AFAICS, they're not, and the issue here is whether every component in
a package must work correctly when that package is installed and its
dependencies satisfied [0].

An appropriate comparison would probably be to dpkg-preconfigure and its
dependency on apt-utils while debconf only Recommends: apt-utils. The
error message isn't as abrupt as cardinfo's, perhaps, but it's still
the same "problem".

Personally, I don't see the value in trying to make this some sort of
hard and fast rule: having either of the above programs in separate
packages isn't likely to make anyone's life easier, and quite frankly
I'd much rather go with the maintainers' judgements than lintian's.

Of course, my thoughts on this sort of thing are on record in bug 102213,
I suppose.

Cheers,
aj

[0] Although there are two provisos you could add to this. One is to limit
    which bits need to be functional: eg, examples of hooking two
    separate programs together in /usr/share/doc are probably okay
    to have installed even if only one of the two programs is; and
    modules in /usr/lib/foo/ that're activated precisely when some other
    program/library is available is probably reasonable too. So you could
    only decide to care about programs in the various bin/ directories,
    and directly in /lib or /usr/lib.

    The other escape that's probably necessary, for an ultra-strict
    reading, is things that can't be satisfied by simply installing
    other software.  So just because iptables can only be used on 2.4.x
    kernels shouldn't mean we have to have some special uninstaller
    in /etc/init.d for machines that dual boot, or similar. (Ditto for
    missing displays, or the lack of PCMCIA hardware, or kernels without
    a module built in, or similar)

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

 "Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
   C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
    can't deal with deconstructionist humor. Code Blue."
		-- Mike Hoye,
		      see http://azure.humbug.org.au/~aj/armadillos.txt
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Sam Hartman <hartmans@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #110 received at 119517@bugs.debian.org (full text, mbox):

From: Sam Hartman <hartmans@debian.org>
To: brian@debian.org (Brian Mays)
Cc: 119517@bugs.debian.org, debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: 17 Nov 2001 10:42:23 -0500
>>>>> "Brian" == Brian Mays <brian@debian.org> writes:


    Brian> My argument is as follows:

    Brian> Programs fail to run for all sorts of reasons and often do
    Brian> not give friendly error messages, help text, etc.  Problems
    Brian> are not only caused by missing libraries, but also missing
    Brian> data or other executables that the program expects to run.
    Brian> I fail to see the difference between a program that is
    Brian> useless because a library is missing and a program that is
    Brian> useless because it is a frontend for another program that
    Brian> is missing.  The program in question does not even need to
    Brian> be useless altogether; many programs fail in unusual or
    Brian> confusing ways when the user activates an obscure feature
    Brian> of the program that requires data or other programs that
    Brian> are missing.

And all of these are bugs. And if the bug is sufficiently frustrating
to the user, it is a serious bug because it makes te package
unsuitable for release.  If no part of the package functions because
of such a bug it may even be grave or critical.

I'd be perfectly happy with a package that wanted some shared library
only recommending or suggesting that shared library, provided that a
wrapper script was included for the programs that did not function
without the shared library to provide a useful error.

Note that even if you include the wrapper script you may still have a
bug for wasting space rather than splitting the package.  Such a bug
is likely to be fairly minor and its existence depends on several
tradeoffs.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to brian@debian.org (Brian Mays):
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #115 received at 119517@bugs.debian.org (full text, mbox):

From: brian@debian.org (Brian Mays)
To: Sam Hartman <hartmans@debian.org>
Cc: 119517@bugs.debian.org, debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Sat, 17 Nov 2001 12:08:35 -0500
Sam Hartman <hartmans@debian.org> wrote:

> I'd be perfectly happy with a package that wanted some shared library
> only recommending or suggesting that shared library, provided that a
> wrapper script was included for the programs that did not function
> without the shared library to provide a useful error.

Rather than providing a script in each of such package, and duplicating
the same work over and over, why not follow the second of Ian Jackson's
suggestions:

: (b) The libc maintainer could choose to `improve' the error message
: from ld.so so that it was considered suitable for the kinds of users
: Branden presumably wants to avoid seeing it.

This, if done right, would fix the problem once and for all, instead of
on a case by case basis.

Of course, good documentation is probably the best way to handle all
of this.  Adding a note in the description that xlibs is needed to run
cardinfo is probably the most useful thing that can be done for the
user.

Sam Hartman <hartmans@debian.org> also wrote:

> Note that even if you include the wrapper script you may still have
> a bug for wasting space rather than splitting the package.  Such a
> bug is likely to be fairly minor and its existence depends on several
> tradeoffs.

I don't follow you here.  Surely you don't suggest that a tiny script
would require more space than the overhead associated with an additional
package, do you?  Chances are, the size of such a script would not be
much larger than the space required to store only the description (i.e.,
control file data) of the new package.  Imagine the difference when we
consider the additional directories and files (copyright, changelog,
etc.) that are required by policy to be included in *each* package.

- Brian



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #120 received at 119517@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 119517@bugs.debian.org, debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Sat, 17 Nov 2001 12:54:51 -0500
[Message part 1 (text/plain, inline)]
On Sat, Nov 17, 2001 at 12:08:35PM -0500, Brian Mays wrote:
> Of course, good documentation is probably the best way to handle all
> of this.  Adding a note in the description that xlibs is needed to run
> cardinfo is probably the most useful thing that can be done for the
> user.

Of course you realize that users do not, in general, read the extended
descriptions of packages.

This isn't your fault, just a bitter lesson I've learned over the past
few years.

-- 
G. Branden Robinson                |
Debian GNU/Linux                   |              It tastes good.
branden@debian.org                 |              -- Bill Clinton
http://people.debian.org/~branden/ |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #125 received at 119517@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: debian-policy@lists.debian.org
Cc: 119517@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sat, 17 Nov 2001 12:57:00 -0500
[Message part 1 (text/plain, inline)]
On Sat, Nov 17, 2001 at 12:24:20AM -0500, Joey Hess wrote:
> Why are ELF objects so special?

Brian Mays and I have asked the Technical Committee for a ruling.  It's
good form to constrain the scope of that ruling as narrowly as is
reasonable.

> If we have a rule like this, why should it not apply to other forms of
> binaries, or to programs written in interpreted languages? Perl and
> python programs can produce ghastly errors if a library they require
> is not installed.
> 
> Also, I'd hope that a perl or python program that requires a library
> from non-free to work has no more business in main than does a ELF
> executable with similar requirements.

I completely agree with you.  However, perl and python scripts are not
at issue before the Technical Committee at present.

-- 
G. Branden Robinson                |       Yesterday upon the stair,
Debian GNU/Linux                   |       I met a man who wasn't there.
branden@debian.org                 |       He wasn't there again today,
http://people.debian.org/~branden/ |       I think he's from the CIA.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to brian@debian.org (Brian Mays):
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #130 received at 119517@bugs.debian.org (full text, mbox):

From: brian@debian.org (Brian Mays)
To: 119517@bugs.debian.org, debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Sat, 17 Nov 2001 13:11:26 -0500
Branden Robinson <branden@debian.org> wrote:

> Of course you realize that users do not, in general, read the extended
> descriptions of packages.
>
> This isn't your fault, just a bitter lesson I've learned over the past
> few years.

I've learned that too.  They also don't read the documentation in
/usr/share/doc/.

- Brian



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #135 received at 119517@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: brian@debian.org (Brian Mays), 119517@bugs.debian.org
Cc: Sam Hartman <hartmans@debian.org>, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Sat, 17 Nov 2001 21:12:56 +0000 (GMT)
Brian Mays writes ("Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package "):
> Rather than providing a script in each of such package, and duplicating
> the same work over and over, why not follow the second of Ian Jackson's
> suggestions:
> 
> : (b) The libc maintainer could choose to `improve' the error message
> : from ld.so so that it was considered suitable for the kinds of users
> : Branden presumably wants to avoid seeing it.

Just to clarify: I do not support this idea, hence my use of scare
quotes.

> Of course, good documentation is probably the best way to handle all
> of this.  Adding a note in the description that xlibs is needed to run
> cardinfo is probably the most useful thing that can be done for the
> user.

Indeed.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #140 received at 119517@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Branden Robinson <branden@debian.org>
Cc: 119517@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sat, 17 Nov 2001 21:15:21 +0000 (GMT)
Branden Robinson writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package"):
> On Sat, Nov 17, 2001 at 12:24:20AM -0500, Joey Hess wrote:
> > Why are ELF objects so special?
> 
> Brian Mays and I have asked the Technical Committee for a ruling.  It's
> good form to constrain the scope of that ruling as narrowly as is
> reasonable.

Nonsense.  The Technical Committee should make whatever specific or
general ruling it sees fit, according to the Constitution.

Furtheremore, when making any decision, the Committee should consider
everything it thinks is relevant, and try to foresee future
requirements and decisions, and try to be consistent and coherent.  So
even if we constrain our formal decision to the case in point, related
questions are relevant.  We must satisfy ourselves that our decisions
are generally internally and externally consistent.

So, I ask again: why are ELF objects so special ?

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #145 received at 119517@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: brian@debian.org (Brian Mays)
Cc: 119517@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Sat, 17 Nov 2001 21:17:35 +0000 (GMT)
Brian Mays writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package "):
> Branden Robinson <branden@debian.org> wrote:
> > Of course you realize that users do not, in general, read the extended
> > descriptions of packages.
> >
> > This isn't your fault, just a bitter lesson I've learned over the past
> > few years.
> 
> I've learned that too.  They also don't read the documentation in
> /usr/share/doc/.

It is not our job to coddle users who won't read the documentation
when something goes wrong.  We should leave that kind of shit to other
distributions.  In general, we should not consider unreasonable
behaviour by users, unless the cost of doing so is minimal.

Anything else means that we are willing to trade off functionality,
usefulness, efficiency or useability for reasonable users, for the
benefit of unreasonable users, which would be unfair.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #150 received at 119517@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: Ian Jackson <ian@davenant.greenend.org.uk>
Cc: 119517@bugs.debian.org, debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sat, 17 Nov 2001 18:53:47 -0500
[Message part 1 (text/plain, inline)]
On Sat, Nov 17, 2001 at 09:15:21PM +0000, Ian Jackson wrote:
> Nonsense.  The Technical Committee should make whatever specific or
> general ruling it sees fit, according to the Constitution.

Constitution 6.3.5:

  No detailed design work.

  The Technical Committee does not engage in design of new proposals and
  policies. Such design work should be carried out by individuals
  privately or together and discussed in ordinary technical policy and
  design forums.

  The Technical Committee restricts itself to choosing from or adopting
  compromises between solutions and decisions which have been proposed
  and reasonably thoroughly discussed elsewhere.

I ask that the Technical Committe restrict itself to choosing from or
adopting a compromise between the solutions proposed by Brian Mays and
myself.

-- 
G. Branden Robinson                |       Yesterday upon the stair,
Debian GNU/Linux                   |       I met a man who wasn't there.
branden@debian.org                 |       He wasn't there again today,
http://people.debian.org/~branden/ |       I think he's from the CIA.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #155 received at 119517@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Branden Robinson <branden@debian.org>, 119517@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sun, 18 Nov 2001 01:20:58 +0000 (GMT)
Branden, you have still not answered this question:
> Branden Robinson writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package"):
> > On Sat, Nov 17, 2001 at 12:24:20AM -0500, Joey Hess wrote:
> > > Why are ELF objects so special?
> > 
> > Brian Mays and I have asked the Technical Committee for a ruling.  It's
> > good form to constrain the scope of that ruling as narrowly as is
> > reasonable.
...
> Furtheremore, when making any decision, the Committee should consider
> everything it thinks is relevant, and try to foresee future
> requirements and decisions, and try to be consistent and coherent.  So
> even if we constrain our formal decision to the case in point, related
> questions are relevant.  We must satisfy ourselves that our decisions
> are generally internally and externally consistent.
> 
> So, I ask again: why are ELF objects so special ?

Do you have an answer ?

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #160 received at 119517@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Branden Robinson <branden@debian.org>, 119517@bugs.debian.org
Cc: debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sun, 18 Nov 2001 01:02:39 +0000 (GMT)
Branden Robinson writes ("Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package"):
> Constitution 6.3.5:
[...]

I have replied to Branden (CC the Committee list) separately.  Please
see my earlier comments about crossposting between debian-policy and
debian-ctte.

Thanks,
Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@azure.humbug.org.au>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #165 received at 119517@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: debian-ctte@lists.debian.org
Cc: Ian Jackson <ian@davenant.greenend.org.uk>, 119517@bugs.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sun, 18 Nov 2001 13:56:14 +1000
[Message part 1 (text/plain, inline)]
On Sat, Nov 17, 2001 at 06:53:47PM -0500, Branden Robinson wrote:
> On Sat, Nov 17, 2001 at 09:15:21PM +0000, Ian Jackson wrote:
> > Nonsense.  The Technical Committee should make whatever specific or
> > general ruling it sees fit, according to the Constitution.
> Constitution 6.3.5:
>   No detailed design work.
>   The Technical Committee does not engage in design of new proposals and
>   policies. Such design work should be carried out by individuals
>   privately or together and discussed in ordinary technical policy and
>   design forums.
>   The Technical Committee restricts itself to choosing from or adopting
>   compromises between solutions and decisions which have been proposed
>   and reasonably thoroughly discussed elsewhere.

Oddly, you missed quoting:

       Individual members of the technical committee may of course
       participate on their own behalf in any aspect of design and policy
       work.

> I ask that the Technical Committe restrict itself to choosing from or
> adopting a compromise between the solutions proposed by Brian Mays and
> myself.

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.

 "Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
   C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
    can't deal with deconstructionist humor. Code Blue."
		-- Mike Hoye,
		      see http://azure.humbug.org.au/~aj/armadillos.txt
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to tb@becket.net (Thomas Bushnell, BSG):
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #170 received at 119517@bugs.debian.org (full text, mbox):

From: tb@becket.net (Thomas Bushnell, BSG)
To: brian@debian.org (Brian Mays)
Cc: 119517@bugs.debian.org, debian-ctte@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: 17 Nov 2001 21:10:11 -0800
brian@debian.org (Brian Mays) writes:

> I've learned that too.  They also don't read the documentation in
> /usr/share/doc/.

And really, how could they?  My *laptop* has 884 packages installed.
If I try "wc /usr/share/doc/*/README.Debian", that alone is:

   4449   24692  168612 total

To expect me to read and understand that much is crazy.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to brian@debian.org (Brian Mays):
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #175 received at 119517@bugs.debian.org (full text, mbox):

From: brian@debian.org (Brian Mays)
To: "Thomas Bushnell, BSG" <tb@becket.net>
Cc: 119517@bugs.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Sun, 18 Nov 2001 09:50:42 -0500
> brian@debian.org (Brian Mays) writes:
>
> > I've learned that too.  They also don't read the documentation in
> > /usr/share/doc/.

"Thomas Bushnell, BSG" <tb@becket.net> added:

> And really, how could they?  My *laptop* has 884 packages installed.
> If I try "wc /usr/share/doc/*/README.Debian", that alone is:
>
>    4449   24692  168612 total

> To expect me to read and understand that much is crazy.

True, but they often don't look to the documentation in
/usr/share/doc/<package>, when they experience a problem with a specific
package.  Thus, it is often tempting to try to find a way to force
information on the user, even when its inappropriate to do so.  See
the recent (and short) thread on the "misuse of debconf notes" in
debian-devel for an example.

Of course, considering the number of subdirectories in /usr/share/doc
already (currently 676 on my labtop), this is a good argument against
requiring us to split things off into yet more tiny packages.

- Brian



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #180 received at 119517@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: debian-policy@lists.debian.org
Cc: 119517@bugs.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sun, 18 Nov 2001 12:12:47 -0500
[Message part 1 (text/plain, inline)]
On Sun, Nov 18, 2001 at 01:02:41AM +0000, Ian Jackson wrote:
> Branden Robinson writes ("Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package"):
> > On Sat, Nov 17, 2001 at 09:15:21PM +0000, Ian Jackson wrote:
> > > Nonsense.  The Technical Committee should make whatever specific or
> > > general ruling it sees fit, according to the Constitution.
> > 
> > Constitution 6.3.5:
> [...]
> 
> Thanks for that.  <sarcasm> I'm sure that the most helpful thing we
> could do at this point is lawyering the Constitution. </>

<sarcasm>
Yes, I can see how noting the difference between "the Technical
Commitee restricts itself to...<x>" and "the Technical Committee
should make...whatever ruling it sees fit" is lawyering.
</sarcasm>

The existence of any constraint <x> logically precludes absolute
discretion.

> Why don't you wait and see what the Committee decides and see if you
> think it meets your idea of these requirements ?

Because the Technical Committee's decision is not legitimate or binding
if it is not constitutional.  The Constitution does not provide a
mechanism for invalidating TC rulings if they are in fact illegimate (or
even for identifying them as such), so if the TC goes ahead and acts in
this manner it will provoke yet another GR to amend the Constitution,
and the concomitant interminable debate.

I think it would save everyone a lot of time of the TC just behaved
as the Constitution instructs, instead of resorting to extralegal
measures.

Of course I shouldn't tar the entire TC with this brush; perhaps it is
only you that is seriously entertaining expansionist notions of the
Technical Committee's powers.

I have restored the CC to the bug report at issue, because it is unclear
to me whether debian-ctte will ever be archived again, and I think it is
worthwhile to have record of these discussions.

-- 
G. Branden Robinson                |     Reality is what refuses to go away
Debian GNU/Linux                   |     when I stop believing in it.
branden@debian.org                 |     -- Philip K. Dick
http://people.debian.org/~branden/ |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #185 received at 119517@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: Ian Jackson <ian@davenant.greenend.org.uk>
Cc: 119517@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sun, 18 Nov 2001 12:22:52 -0500
[Message part 1 (text/plain, inline)]
On Sun, Nov 18, 2001 at 01:20:58AM +0000, Ian Jackson wrote:
> Branden, you have still not answered this question:
> > So, I ask again: why are ELF objects so special ?
> 
> Do you have an answer ?

ELF objects are special because they are the actual matter at issue.

Shell scripts, documentation, the format of debian/control files, and
other matters the Debian Policy Manual addresses, are not.

I reiterate my request for the Technical Committee to conduct itself as
directed in the Debian Constitution (particularly clause 6.3.5) since
there seems to some temptation towards scope creep in this ruling, the
nature of which both advocates (Brian Mays and myself) agree upon and do
not dispute.  We asked for a specific, interpretive ruling on a narrow
point that would be binding for the woody release, since the Policy
Manual is presently frozen under the authority of the Release Manager.
Please render that.  Anything broader can and probably should be tackled
by the Developers for inclusion in a post-woody revision of the Policy
Manual.

-- 
G. Branden Robinson                |     No math genius, eh?  Then perhaps
Debian GNU/Linux                   |     you could explain to me where you
branden@debian.org                 |     got these...       PENROSE TILES!
http://people.debian.org/~branden/ |     -- Stephen R. Notley
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Dale Scheetz <dwarf@polaris.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #190 received at 119517@bugs.debian.org (full text, mbox):

From: Dale Scheetz <dwarf@polaris.net>
To: Brian Mays <brian@debian.org>
Cc: debian-ctte@lists.debian.org, <119517@bugs.debian.org>
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sun, 18 Nov 2001 13:02:34 -0500 (EST)
OK, it looks to me like there are 3 sticking points:

1. The difference between a package and a binary element.

2. The multiple usage of the term Depends.

3. How to apply "significant" in this situation.

And one technical issue that should be addressed, namely seeking a balance
between delivered functionality and system configuration requirements. I
suspect that my perceptions lean toward delivered functionality...

1. Many packages have only one executable element. Probably as many have
more than one element. One of the questions to be answered is: "To which
does the dependency associate, the package or the element."

As an example of a package I'm familiar with ;-) consider the atari800
package. There are 4 executable elements; 1 shell script, on svgalib bin,
onr ncurses bin, and one x11 bin. The Depends: line for the package
contains a dependency entry for each of the elements. I interpret this to
mean that the package inherits the dependencies of its components.

2. The term depend is used in two different contexts within this policy
issue. It is, on the one hand, used as the name of a class of fields used
to manage the installation process, but it is also the name of one of the
actual sub-classes within the context of depends. This makes it possible
to interpret the same policy in two different fashions. Please note that I
was able to describe the class of terms to which Depends: and Suggests:
fields belong, without resorting to the term "dependency". This class
breaks the level to which this package is associated with other packages
into defined levels.

For the sake of clarity, for the remainder of this e-mail, I will try to
use the term "Absolute:" to refer to the dependency field Depends:

3. What does "significant" mean in the context that policy uses it? The
dictionary says significant = important.

OK, _suppose_ that cardinfo is a single binary delivered in the cardinfo
package with no other binary elements. I think, under these circumstances,
we would both agree that it would be significant if cardinfo failed to
execute after the package is installed, right? The dependency of the
binary on the X libraries is clearly an Absolute: dependency.

Now my question is: "Why should this absolute dependency be reduced when
this binary is included with the "server" side software in a larger
package?"

My position is that it should not. I have to reasons for this assertion.
First it delivers the same functionality one would expect from the split
package. Consider other examples like procps. This package contains around
16 binary elements. Which are "significant" and which aren't. I say we
should not be asking this question. If the element is not important to the
package needs, then it should be delivered as a separate package so that
those who don't need it are un-encombered with its presence, and those who
do need it can install it along with its dependent packages.

So, my argument goes: If it isn't important, and you don't want to
encomber the package with this element's absolute dependencies, then you
split it off. If it is important, its absolute dependencies should be
reflected at that level in the package Depends:.

I choose this interpretation because it doesn't matter which way the
maintainer swings on the issue of the importance of a component, the end
user is served a functioning set of packages.

In your situation, you don't qualify cardinfo as "important" to the
function of the pcmcia package, and the bug submitter thinks it is. If you
follow the policy I have suggested, you would either agree that it was
important enough to enclude in the package, and declare its absolute
dependency in the Depends: field, or choose to disagree and thus move the
unimportant component into an "extra" priority package of its own.

The current policy documents are clear to me, assuming the definitions I
suggested are imposed. You have two choices as I read policy: split off
cardinfo and declare the X libraries in the Depends: field, or keep it in
the current package and include the X libraries in the Depends: field. If
it were my package, I'd split it off...

I realize I'm only one member of this committee, and outside of Ian's
initial comments I have no idea how the rest of the committee feels about
this issue. I think I've made my points as clear as I am able, so I don't
think I have anything more to say. I'll leave it up to the committee as a
whole to come to a decission...

BTW, should we really be cc'ing this discussion to the BTS, or is CTTE
sufficient?

Waiting is,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-                                                                    _-
_- aka   Dale Scheetz                   Phone:   1 (850) 656-9769     _-
_-       Flexible Software              11000 McCrackin Road          _-
_-       e-mail:  dwarf@polaris.net     Tallahassee, FL  32308        _-
_-                                                                    _-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
              available at: http://www.polaris.net/~dwarf/




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #195 received at 119517@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Branden Robinson <branden@debian.org>
Cc: 119517@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sun, 18 Nov 2001 18:29:52 +0000 (GMT)
Branden Robinson writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package"):
> On Sun, Nov 18, 2001 at 01:20:58AM +0000, Ian Jackson wrote:
> > Branden, you have still not answered this question:
> > > So, I ask again: why are ELF objects so special ?
> > 
> > Do you have an answer ?
> 
> ELF objects are special because they are the actual matter at issue.

Don't be disingenuous.

> Shell scripts, documentation, the format of debian/control files, and
> other matters the Debian Policy Manual addresses, are not.

As I wrote earlier:

 Furtheremore, when making any decision, the Committee should consider
 everything it thinks is relevant, and try to foresee future
 requirements and decisions, and try to be consistent and coherent.  So
 even if we constrain our formal decision to the case in point, related
 questions are relevant.  We must satisfy ourselves that our decisions
 are generally internally and externally consistent.

We cannot do our job properly if we don't think about the wider
picture.  Are you going to help us by cooperating in our discussions,
or shall we just assume you don't have a good answer, and make our
decision without that part of your input ?

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to brian@debian.org (Brian Mays):
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #200 received at 119517@bugs.debian.org (full text, mbox):

From: brian@debian.org (Brian Mays)
To: Dale Scheetz <dwarf@polaris.net>
Cc: debian-ctte@lists.debian.org, 119517@bugs.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sun, 18 Nov 2001 16:08:40 -0500
Dale Scheetz <dwarf@polaris.net> wrote:

> OK, it looks to me like there are 3 sticking points:
>
> 1. The difference between a package and a binary element.
>
> 2. The multiple usage of the term Depends.
>
> 3. How to apply "significant" in this situation.
>
> And one technical issue that should be addressed, namely seeking a
> balance between delivered functionality and system configuration
> requirements. I suspect that my perceptions lean toward delivered
> functionality...

Your points are well taken, and I understand how you have reached
your decision.  I'm afraid, however, that we shall have to agree to
disagree.  While your perceptions lean toward delivered functionality,
my perceptions lean towards manageability and flexibility.

You are absolutely correct that the goal is to seek a balance, and
whatever we choose to do will be a compromise of sorts.  A packaging
system that is too finely granulated quickly becomes unwieldy; one with
insufficient detail also becomes less useful.

Our ideas of what constitutes a package, however, are somewhat
different.  Your definition is centered on specific programs.
Therefore, if a user says, "I want program X," he or she should be
able to install a package and get this program, with all necessary
requirements for X fulfilled.

My definition is centered on utility (what the policy manual calls
"functionality").  In this definition, it is sufficient for the user
to say, "I want my computer to do X," in which case he or she can
install a package and get this capability.  This package may contain
many tools and utilities related to this function, some of which the
user may not care about.  Therefore, he or she should be free to ignore
these programs and their requirements.  In the end, I think that it is
better to keep related tools from the same source together, rather than
scattering them throughout (potentially) many separate packages.

As to "encumbering" users with the presence of unnecessary elements,
I'd like to point out that we already do this, and examples are not
difficult to find.  Consider the cpio package, which is installed on
almost every Debian system, since it has a priority of "important."
This package also contains GNU mt.  Why?  Because mt is delivered as
part of the GNU cpio source, and because splitting off a package with
two tiny binaries (mt and it's companion rmt) is a waste.  Therefore,
most Debian systems come with mt, but I think that it is safe to say
that most Debian users never use it.

Just as I understand your position on this matter and how you reached
it, I hope that you are able to understand my interpretation of
policy.  With my definition of a package and with my philosophy toward
delivering packages that provide functionality, but perhaps not total
functionality, the text of the policy manual also becomes clear, but
does not result in the same conclusion as the one that you have reached.
Neither of us can claim to be absolutely correct, since at least two
developers, Branden Robinson and I, have agreed that the manual is vague
enough to ask for a decision from the Technical Committee.  (By the way,
I don't think that Branden Robinson and I disagree on how important
cardinfo is to the pcmcia-cs package.  We disagree on what should be
done with it.)

I hope that the committee members will take into consideration all
aspects of this question and all ramifications of the final decision,
since my objections to this bug report hinge on these larger issues.
Sure, it is easy to split cardinfo into its own package, but if we
dictate that it must be done on this occasion, then we essentially
have mandated that similar splitting of packages must be done on many
occasions.  I have already expressed my opinion several times that the
disadvantages of this excess package fragmentation out way any perceived
advantages of providing extremely strict dependencies.

Please forgive me for writing such a long message.  It appears that both
sides have thoroughly discussed their positions, and I hope that I shall
not need to write further on this issue.

- Brian



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #205 received at 119517@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: Ian Jackson <ian@davenant.greenend.org.uk>
Cc: 119517@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Sun, 18 Nov 2001 20:16:55 -0500
[Message part 1 (text/plain, inline)]
On Sun, Nov 18, 2001 at 06:29:52PM +0000, Ian Jackson wrote:
> Branden Robinson writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package"):
> > On Sun, Nov 18, 2001 at 01:20:58AM +0000, Ian Jackson wrote:
> > > Branden, you have still not answered this question:
> > > > So, I ask again: why are ELF objects so special ?
> > > 
> > > Do you have an answer ?
> > 
> > ELF objects are special because they are the actual matter at issue.
> 
> Don't be disingenuous.

I'm not being disingenuous.

Does the "dependency" that packages must declare on the shared libraries
against which their ELF objects (binaries + shared libraries) depend
have to be a "Depends:", or can it be something else?

> We cannot do our job properly if we don't think about the wider
> picture.

The wider picture doesn't have to do with dpkg-shlibdeps.  If we had (at
least, in common use) some tool that automatically determined perl
module dependencies, python dependencies, or scanned shell scripts for
non-Essential commands used, that might have an impact on my opinion.

However, package maintainers generally just stuff ${shlibs:Depends} into
their control files, call dpkg-shlibdeps or dh_shlibdeps from the rules
file, and don't worry any more about it.

ELF dependencies are de facto handled specially in Debian packages.
Whether we should treat ELF dependencies differently from the other
types of dependency I mentioned above is a question that is neither
uninteresting nor unimportant, but it is clearly outside the scope of
the determination the Technical Committee is being asked to make.  Again
and again I have stated that I think the proper approach for Policy in
the post-woody era is for the Debian Policy group to handle these larger
issues.  Any member of the Technical Committee that feels strongly about
them should participate in that process, as an individual Developer, not
as a member of the Technical Committee, exactly as the Constitution
directs in 6.3.5.

I don't know what is so offensive to you about this, unless it's the
distate you have personally expressed for the current mechanism Debian
has in place for maintaining the Policy Manual (I can't find a cite for
your messages on this subject offhand, but I could be persuaded to look
harder).  If that is the case, I suggest that expanding the role of the
Technical Committee is an inappropriate response, at least until a
Consitutional amendment has been passed that redefines the Technical
Committee's powers thus.

> Are you going to help us by cooperating in our discussions, or shall
> we just assume you don't have a good answer, and make our decision
> without that part of your input ?

I have already described why I think my opinions on phenomena beyond the
scope of the point at issue shouldn't matter.  It's not as if I believe
you'd give them weight even if I did offer them, since I suspect you see
the current issue as more a platform for your meta-Policy activism than
as an issue to be judged in its own right.  Please feel free to prove me
wrong by sticking to the spirit and letter of clause 6.3.5.

-- 
G. Branden Robinson                |    If you make people think they're
Debian GNU/Linux                   |    thinking, they'll love you; but if
branden@debian.org                 |    you really make them think, they'll
http://people.debian.org/~branden/ |    hate you.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Jason Gunthorpe <jgg@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #210 received at 119517@bugs.debian.org (full text, mbox):

From: Jason Gunthorpe <jgg@debian.org>
Cc: debian-ctte@lists.debian.org, 119517@bugs.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Date: Mon, 19 Nov 2001 21:50:23 -0700 (MST)
On Sun, 18 Nov 2001, Dale Scheetz wrote:

> The current policy documents are clear to me, assuming the definitions I
> suggested are imposed. You have two choices as I read policy: split off
> cardinfo and declare the X libraries in the Depends: field, or keep it in
> the current package and include the X libraries in the Depends: field. If
> it were my package, I'd split it off...

I agree with this FWIW

I also tend to reject the notion that a large number of packages is
extremely bad..

Jason




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #215 received at 119517@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: <adconrad@0c3.net>
Cc: <119517@bugs.debian.org>, <debian-ctte@lists.debian.org>
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Mon, 03 Dec 2001 19:23:14 -0600
>>"Adam" == Adam Conrad <adconrad@0c3.net> writes:

 Adam> I'm going to lend my two cents here and agree with the people who think
 Adam> that "Suggests" is good enough for this particular dependency.

 Adam> If we believe that "installation of a package must require that all
 Adam> functionality of said package functions after installation" we have a
 Adam> LOT of packages that don't conform to this ideal.

 Adam> Example 1:

 Adam> kernel-source-x.x.x packages:

 Adam> Without libncurses5-dev, "make menuconfig" doesn't work.
 Adam> Without tcl/tk, "make xconfig" doesn't work.

	Both restrictions documented, and really, one of the three
 ways to arrive at the same functionality. You can reach the desired
 end goal -- of having a configured kernel- as long as the
 dependencies are satisfied.


	Also, never does the kernel-source package say that being able
 to run make {x,menu}config is something you are expected to be able
 to do (If you can find such a reference, please point it to me, since
 that would be a documentation bug).

 Adam> The konqueror web/file browser:

 Adam> Without "kdelibs3-crypto" installed, konqueror won't do SSL.  In today's
 Adam> world, SSL web pages are nearly a MUST for a web browser, so does this
 Adam> mean we have lost "expected functionality", and konqueror should depend
 Adam> on the crypto support, and move to non-US?

	Does konqueror explicitly specidy that SSl is a supported
 protocol? If so, then the dependency should be mandatory.  If it is
 documented as an optional, add on protocol with other requirements,
 then we are OK.If the package ships with a binary that does not work
 without SSL, it is a bug in the package.

	manoj
-- 
 Now and then an innocent man is sent to the legislature.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to <adconrad@0c3.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #220 received at 119517@bugs.debian.org (full text, mbox):

From: "Adam Conrad" <adconrad@0c3.net>
To: "'Manoj Srivastava'" <srivasta@debian.org>
Cc: <119517@bugs.debian.org>, <debian-ctte@lists.debian.org>
Subject: RE: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Tue, 4 Dec 2001 04:30:05 -0700
Manoj,

I don't think we're disagreeing here then.  :)  By your contention, all
that needs to be done is to document 'cardinfo' as an optional portion
of pcmcia-cs (like SSL in Konqueror, or make menu/xconfig in the kernel
source) and then the dependency can be left as is.. A suggest.  No?

... Adam

-----Original Message-----
From: srivasta@golden-gryphon.com [mailto:srivasta@golden-gryphon.com]
On Behalf Of Manoj Srivastava
Sent: Monday, December 03, 2001 6:23 PM
To: adconrad@0c3.net
Cc: 119517@bugs.debian.org; debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a
separate package


>>"Adam" == Adam Conrad <adconrad@0c3.net> writes:

 Adam> I'm going to lend my two cents here and agree with the people who
think
 Adam> that "Suggests" is good enough for this particular dependency.

 Adam> If we believe that "installation of a package must require that
all
 Adam> functionality of said package functions after installation" we
have a
 Adam> LOT of packages that don't conform to this ideal.

 Adam> Example 1:

 Adam> kernel-source-x.x.x packages:

 Adam> Without libncurses5-dev, "make menuconfig" doesn't work.
 Adam> Without tcl/tk, "make xconfig" doesn't work.

	Both restrictions documented, and really, one of the three
 ways to arrive at the same functionality. You can reach the desired
 end goal -- of having a configured kernel- as long as the
 dependencies are satisfied.


	Also, never does the kernel-source package say that being able
 to run make {x,menu}config is something you are expected to be able
 to do (If you can find such a reference, please point it to me, since
 that would be a documentation bug).

 Adam> The konqueror web/file browser:

 Adam> Without "kdelibs3-crypto" installed, konqueror won't do SSL.  In
today's
 Adam> world, SSL web pages are nearly a MUST for a web browser, so does
this
 Adam> mean we have lost "expected functionality", and konqueror should
depend
 Adam> on the crypto support, and move to non-US?

	Does konqueror explicitly specidy that SSl is a supported
 protocol? If so, then the dependency should be mandatory.  If it is
 documented as an optional, add on protocol with other requirements,
 then we are OK.If the package ships with a binary that does not work
 without SSL, it is a bug in the package.

	manoj
-- 
 Now and then an innocent man is sent to the legislature.
Manoj Srivastava   <srivasta@debian.org>
<http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #225 received at 119517@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: <adconrad@0c3.net>
Cc: <119517@bugs.debian.org>, <debian-ctte@lists.debian.org>
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Tue, 04 Dec 2001 10:31:06 -0600
-----BEGIN PGP SIGNED MESSAGE-----

>>"Adam" == Adam Conrad <adconrad@0c3.net> writes:

 Adam> I don't think we're disagreeing here then.  :)  By your contention, all
 Adam> that needs to be done is to document 'cardinfo' as an optional portion
 Adam> of pcmcia-cs (like SSL in Konqueror, or make menu/xconfig in the kernel
 Adam> source) and then the dependency can be left as is.. A suggest.  No?

	Not quite. However, if cardinfo works and provides the
 information on the current set of cards on stdout, and in the
 presence of a DISPLAY variable  provides additional, X based
 functionality, that would be perfectly acceptable, for reasons I have
 detailed in another message.

	manoj
- -- 
 Shaw to William Douglas Home: "Go on writing plays, my boy.  One of
 these days a London producer will go into his office and say to his
 secretary, `Is there a play from Shaw this morning?' and when she
 says `No,' he will say, `Well, then we'll have to start on the
 rubbish.' And that's your chance, my boy."
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iD8DBQE8DPo5Ibrau78kQkwRAXI1AKCoHBmLdQ1MjdBZw1nxXWcsgL1vewCghMKP
0MHA3fELmooqdjgk/Bv8dBs=
=TLr6
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to brian@debian.org (Brian Mays):
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>. Full text and rfc822 format available.

Message #230 received at 119517@bugs.debian.org (full text, mbox):

From: brian@debian.org (Brian Mays)
To: Manoj Srivastava <srivasta@debian.org>, 119517@bugs.debian.org
Cc: adconrad@0c3.net, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Tue, 04 Dec 2001 12:01:03 -0500
    >>> "Adam" == Adam Conrad <adconrad@0c3.net> writes:

    Adam> ... we have a LOT of packages that don't conform
    Adam> to this ideal.

    Adam> Example 1:

    Adam> kernel-source-x.x.x packages:

    Adam> Without libncurses5-dev, "make menuconfig" doesn't work.
    Adam> Without tcl/tk, "make xconfig" doesn't work.

>>>>> "Manoj" == Manoj Srivastava <srivasta@debian.org> writes:

    Manoj> 	Both restrictions documented, and really, one of the
    Manoj> three ways to arrive at the same functionality. You can
    Manoj> reach the desired end goal -- of having a configured
    Manoj> kernel- as long as the dependencies are satisfied.

Please let me remind you that this bug report is about a program whose
restrictions are documented, and really, is one of two ways to arrive
at the same functionality.  You can reach the desired end goal -- of
monitoring and controlling the PCMCIA sockets -- as long as the
("Depends" level) dependencies are satisfied.

    Manoj> 	Also, never does the kernel-source package say that
    Manoj> being able to run make {x,menu}config is something you are
    Manoj> expected to be able to do (If you can find such a
    Manoj> reference, please point it to me, since that would be a
    Manoj> documentation bug).

I can look at the makefile and see that these targets exist.
Therefore, they should simply work or provide a useful error message
if they do not.  That sounds to me at least as valid as your argument
along the lines of "I can see it in /usr/bin, so it should just work."

Both are reasonable assumptions, and both restrictions can be as
easily documented.  Why should kernel-source be able to explain away
an optional functionality, but another package cannot?

If we are talking about each package providing a useful interface to
the user, i.e., a list of capabilities or functions provided by the
package, then the targets of a makefile should be as valid an
interface as the binaries in a directory.  One lists its capabilities
in a file, the other lists them in a directory (which is just another
type of file, or another type of database, if you prefer).

By the way, you did not address all of Adam's message; in particular,
you ignored the part about the wrapper script.  So is it your position
that an absolute dependency is required?  This bug report actually
calls for the package to be split into two packages.  Is that your
position?

- Brian



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Daniel Stone <daniel@sfarc.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #235 received at 119517@bugs.debian.org (full text, mbox):

From: Daniel Stone <daniel@sfarc.net>
To: 119517@bugs.debian.org
Cc: adconrad@0c3.net
Subject: Re: #119517 (wrt: Konq and SSL)
Date: Tue, 26 Feb 2002 21:03:08 +1100
[Message part 1 (text/plain, inline)]
I would just like to clear up a very incorrect assertion:
> In today's world, SSL web pages are nearly a MUST for a web browser,
> so does this mean we have lost "expected functionality", and konqueror
> should depend on the crypto support, and move to non-US?  Or should we
> perhaps have two completely separate builds of ANY KDE application that
> has SSL support, {app|app-ssl}, nearly doubling KDE's size in the archive

This assertion is unfounded and incorrect. Please do your homework
before saying things like this.

Konq knows nothing of the https protocol. A KDE library, kio_https.so,
is generated, which handles all of the functions for secure HTTP. Konq
knows nothing of this, it just passes the URL to KIO raw, without
knowing or caring.

Besides, kde{libs,base}-crypto are independent and tiny packages; Ivan
Moore has done some voodoo to get it to build only the SSL-dependant
libraries. The man is a modern genius.

While I'm here, let me point out that that only causes an error message
within Konqueror when trying to access certain sites. Almost everything
you want to do, will work, when the Depends are satisfied. OTOH,
cardinfo will completely and totally refuse to work. You will get
exactly zero functionality of it, and thus I feel that it must declare a
Depends, not a Suggests.

d

-- 
Daniel Stone						    <daniel@sfarc.net>
* fusion passes out green things
* lilo accepts a green thing from fusion, and has an interesting discussion
with it about the works of Roman Polanski
* Winter waits for lilo to eat the green thing.
* lilo makes a particularly clever remark.  The green thing laughs. lilo
eats the green thing.
* fusion cries
* lilo consoles fusion
* lilo eyes fusion hungrily
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to "Adam Conrad" <adconrad@0c3.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #240 received at 119517@bugs.debian.org (full text, mbox):

From: "Adam Conrad" <adconrad@0c3.net>
To: "'Daniel Stone'" <daniel@sfarc.net>
Cc: <119517@bugs.debian.org>
Subject: RE: #119517 (wrt: Konq and SSL)
Date: Tue, 26 Feb 2002 03:22:27 -0700
Yes, I know the Konqueror example was contrived, and I *DO* realize that
the URL handling all comes from a different library.  The example was
given to prove a point, not to be an exact comparison.

If I install a web browser, and I'm not overly familiar with Debian
policy WRT to crypto export, I expect SSL to work out of the box.  Out
of the box, however, there's a fair chance that it won't work, and the
message if fairly cryptic.  This is an example of a package that
provides most of its functions, but not all.

pcmcia-cs is the same way... cardinfo is a *function* of pcmcia-cs, it's
not the raison d'ĂȘtre of the entire package.  Many people who install
pcmcia-cs probably never even run the cardinfo binary.  I know I
haven't.

All along, however, my argument hasn't been one of "throw dependencies
to the wind, and declare them on a whim", but rather that a simple
wrapper with a friendly "you need package: foo installed to run this
app" would be helpful.  Manoj's suggestion of a fully functional console
version that delivers similar functionality, and launches the X version
if DISPLAY is present is even nicer, but more work.

... Adam




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Daniel Stone <daniel@sfarc.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #245 received at 119517@bugs.debian.org (full text, mbox):

From: Daniel Stone <daniel@sfarc.net>
To: Adam Conrad <adconrad@0c3.net>
Cc: 119517@bugs.debian.org
Subject: Re: #119517 (wrt: Konq and SSL)
Date: Tue, 26 Feb 2002 21:28:24 +1100
[Message part 1 (text/plain, inline)]
On Tue, Feb 26, 2002 at 03:22:27AM -0700, Adam Conrad wrote:
> Yes, I know the Konqueror example was contrived, and I *DO* realize that
> the URL handling all comes from a different library.  The example was
> given to prove a point, not to be an exact comparison.

The doubling of archive thing size was total BS.

> If I install a web browser, and I'm not overly familiar with Debian
> policy WRT to crypto export, I expect SSL to work out of the box.  Out
> of the box, however, there's a fair chance that it won't work, and the
> message if fairly cryptic.  This is an example of a package that
> provides most of its functions, but not all.

It provides *most* of its functions. Seeing as all of its functions but
one peripheral function which is not central to the operation as a web
browser are provided, I see no reason for it to declare a Depends. In
fact, I think it's already declared as a Suggests, which is the perfect
use for it - it will enhance the value of the package, but the package
is far from useless without it.

> pcmcia-cs is the same way... cardinfo is a *function* of pcmcia-cs, it's
> not the raison d'?tre of the entire package.  Many people who install
> pcmcia-cs probably never even run the cardinfo binary.  I know I
> haven't.

Yes, but you are providing a binary. Konq isn't called ssl-browser, or
konqueror-with-ssl-support, or whatever. When you provide a binary, you
must explicitly declare all the Depends needed to make it run.

> All along, however, my argument hasn't been one of "throw dependencies
> to the wind, and declare them on a whim", but rather that a simple
> wrapper with a friendly "you need package: foo installed to run this
> app" would be helpful.  Manoj's suggestion of a fully functional console
> version that delivers similar functionality, and launches the X version
> if DISPLAY is present is even nicer, but more work.

I'm with Manoj's suggestion. I think yours is a quick hack that
shouldn't make it into Debian for fear of setting an ugly precedent.

-- 
Daniel Stone						    <daniel@sfarc.net>
<CheezH> Subject: ssh: shit is fucked
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to "Adam Conrad" <adconrad@0c3.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #250 received at 119517@bugs.debian.org (full text, mbox):

From: "Adam Conrad" <adconrad@0c3.net>
To: "'Daniel Stone'" <daniel@sfarc.net>
Cc: <119517@bugs.debian.org>
Subject: RE: #119517 (wrt: Konq and SSL)
Date: Tue, 26 Feb 2002 03:37:28 -0700
-----Original Message-----
From: Daniel Stone [mailto:daniel@sfarc.net] 

> The doubling of archive thing size was total BS.

Agreed.  I wasn't really paying attention to the layout of the KDE
binaries and libraries when I wrote that.  Heck, I don't even use KDE,
it was just an example pulled out of a hat.  Disregard the archive
doubling thing, then.  The rest still stands.

> Yes, but you are providing a binary. Konq isn't called ssl-browser, or
> konqueror-with-ssl-support, or whatever. When you provide a binary,
you
> must explicitly declare all the Depends needed to make it run.

I think this has been the argument all along, actually.  People are
trying to figure out why "a tiny binary in a large package filled with
binaries" is more important than "a tiny function in a single binary".

> I'm with Manoj's suggestion. I think yours is a quick hack that
> shouldn't make it into Debian for fear of setting an ugly precedent.

FWIW, you're probably right.  Then again, I'm not the maintainer, and I
don't want to be, so my opinion is just that -- opinion.  I don't envy
Brian in the slightest.  pcmcia-cs is a pain. :)

... Adam




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Daniel Stone <daniel@sfarc.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #255 received at 119517@bugs.debian.org (full text, mbox):

From: Daniel Stone <daniel@sfarc.net>
To: Adam Conrad <adconrad@0c3.net>
Cc: 119517@bugs.debian.org
Subject: Re: #119517 (wrt: Konq and SSL)
Date: Tue, 26 Feb 2002 21:41:15 +1100
[Message part 1 (text/plain, inline)]
On Tue, Feb 26, 2002 at 03:37:28AM -0700, Adam Conrad wrote:
> From: Daniel Stone [mailto:daniel@sfarc.net] 
> > Yes, but you are providing a binary. Konq isn't called ssl-browser, or
> > konqueror-with-ssl-support, or whatever. When you provide a binary,
> you
> > must explicitly declare all the Depends needed to make it run.
> 
> I think this has been the argument all along, actually.  People are
> trying to figure out why "a tiny binary in a large package filled with
> binaries" is more important than "a tiny function in a single binary".

Because, by providing a binary, you are implicitly advertising that it
works. If it doesn't work, remove it from the package. As I said, if
Konq was called ssl-browser, or konq-that-works-with-ssl, that'd be a
different matter, but it isn't. This binary doesn't even load. 

> > I'm with Manoj's suggestion. I think yours is a quick hack that
> > shouldn't make it into Debian for fear of setting an ugly precedent.
> 
> FWIW, you're probably right.  Then again, I'm not the maintainer, and I
> don't want to be, so my opinion is just that -- opinion.  I don't envy
> Brian in the slightest.  pcmcia-cs is a pain. :)

Yea, the only laptop I have is a 486 SX/33, so I've never even been able
to experience the pain, but I can imagine it.

-- 
Daniel Stone						    <daniel@sfarc.net>
<xidex> its either skinny 10year old in skimpy dresses jumping up and
down in some so called music video, or movies where its always "big
strong man save world ugh ugh ugh, jane come, save world ugh ugh"
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and filed, but not forwarded. Copy sent to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #260 received at 119517-quiet@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 119517-quiet@bugs.debian.org, debian-ctte@lists.debian.org
Cc: debian-devel@lists.debian.org
Subject: Technical Committee: decision on #119517?
Date: Fri, 19 Apr 2002 01:20:32 -0500
[Message part 1 (text/plain, inline)]
Over six months ago, on 2001-11-14, Bug #119517 was submitted to the
Technical Committee for a ruling.  No member of the Technical Committe
has participated in any public discussion of this bug (at least in the
bug logs or in available messages from the debian-ctte list archives)
since 2001-12-04, and no apparently discussion of any sort since
2002-02-26.

Does the Technical Committee have any plans to issue any statement on
this issue?  Either an affirmative statement regarding the issue on
point, or a statement that the Committee refuses to countenance the
it?  If the latter, please provide some reasoning as to why, as Section
6.3.6 of the Constitution appears to be applicable:

	Technical Committee makes decisions only as last resort.

	The Technical Committee does not make a technical decision until
	efforts to resolve it via consensus have been tried and failed,
	unless it has been asked to make a decision by the person or
	body who would normally be responsible for it.

Note that the "unless" clause is applicable here, as the package
maintainer explicitly requested a ruling from the Technical Committee.
In fact, both disputants made such a request.

Thanks for your attention.

-- 
G. Branden Robinson                |    It was a typical net.exercise -- a
Debian GNU/Linux                   |    screaming mob pounding on a greasy
branden@debian.org                 |    spot on the pavement, where used to
http://people.debian.org/~branden/ |    lie the carcass of a dead horse.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Jamie Wilkinson <jaq@debian.org>:
Extra info received and filed, but not forwarded. Copy sent to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #265 received at 119517-quiet@bugs.debian.org (full text, mbox):

From: Jamie Wilkinson <jaq@debian.org>
To: 119517-quiet@bugs.debian.org, debian-ctte@lists.debian.org, debian-devel@lists.debian.org
Subject: Re: Technical Committee: decision on #119517?
Date: Fri, 19 Apr 2002 18:20:16 +1000
This one time, at band camp, Branden Robinson wrote:
>Over six months ago, on 2001-11-14, Bug #119517 was submitted to the
>Technical Committee for a ruling.  No member of the Technical Committe
>has participated in any public discussion of this bug (at least in the
>bug logs or in available messages from the debian-ctte list archives)
>since 2001-12-04, and no apparently discussion of any sort since
>2002-02-26.

As Brian has made it clear[1] that he does not wish to follow either
suggestion made by Dale Scheetz[2] (splitting the package or changing the
Depends:) to ensure all executables supplied in the package run as expected,
IMHO the solution is as Ian Jackson proposed:

|(a) The pcmcia-cs maintainer could choose to make `cardinfo' be a
|script which checked whether the appropriate libraries were present
|and otherwise produced a more helpful error message.

Bugs that turn into political debates are boring.

[1] <20011118210841.D92F6DFB3@ariel.local.net>
[2] <Pine.LNX.4.40.0111181149200.351-100000@dwarf2>
-- 
jaq@spacepants.org                           http://spacepants.org/jaq.gpg
 
The ability to quote is a serviceable substitute for wit.
        -- W. S. Maugham



Information forwarded to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Jochen Voss <jvoss2@web.de>:
Extra info received and filed, but not forwarded. Copy sent to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #270 received at 119517-quiet@bugs.debian.org (full text, mbox):

From: Jochen Voss <jvoss2@web.de>
To: debian-devel@lists.debian.org
Cc: 119517-quiet@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Technical Committee: decision on #119517?
Date: Fri, 19 Apr 2002 12:59:22 +0200
[Message part 1 (text/plain, inline)]
Hallo?

On Fri, Apr 19, 2002 at 01:20:32AM -0500, Branden Robinson wrote:
> Over six months ago, on 2001-11-14, [...]
Huh?  At what time do you live?

Confused,
Jochen
-- 
                                         Omm
                                      (0)-(0)
http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Nathan E Norman <nnorman@micromuse.com>:
Extra info received and filed, but not forwarded. Copy sent to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #275 received at 119517-quiet@bugs.debian.org (full text, mbox):

From: Nathan E Norman <nnorman@micromuse.com>
To: debian-devel@lists.debian.org
Cc: 119517-quiet@bugs.debian.org
Subject: Re: Technical Committee: decision on #119517?
Date: Fri, 19 Apr 2002 06:11:51 -0500
[Message part 1 (text/plain, inline)]
On Fri, Apr 19, 2002 at 12:59:22PM +0200, Jochen Voss wrote:
> Hallo?
> 
> On Fri, Apr 19, 2002 at 01:20:32AM -0500, Branden Robinson wrote:
> > Over six months ago, on 2001-11-14, [...]
                            ^    ^  ^
                            |    |  |
                      Year -+    |  |
                          Month -+  |
                               Day -+

> Huh?  At what time do you live?

-- 
Nathan Norman - Micromuse Ltd.  mailto:nnorman@micromuse.com
Gil-galad was an Elven-king.            |  The Fellowship
Of him the harpers sadly sing:          |        of
the last whose realm was fair and free  |     the Ring
between the Mountains and the Sea.      |  J.R.R. Tolkien
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and filed, but not forwarded. Copy sent to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #280 received at 119517-quiet@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: debian-devel@lists.debian.org
Cc: 119517-quiet@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Technical Committee: decision on #119517?
Date: Fri, 19 Apr 2002 10:48:20 -0500
[Message part 1 (text/plain, inline)]
On Fri, Apr 19, 2002 at 12:59:22PM +0200, Jochen Voss wrote:
> Hallo?
> 
> On Fri, Apr 19, 2002 at 01:20:32AM -0500, Branden Robinson wrote:
> > Over six months ago, on 2001-11-14, [...]
> Huh?  At what time do you live?

That's ISO 8601 date format.  However, s/six months/five months/, sorry.

Maybe last year felt like it was 13 months long.  ;-)

-- 
G. Branden Robinson                |
Debian GNU/Linux                   |       Extra territorium jus dicenti
branden@debian.org                 |       impune non paretur.
http://people.debian.org/~branden/ |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and filed, but not forwarded. Copy sent to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #285 received at 119517-quiet@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: 119517-quiet@bugs.debian.org
Cc: debian-ctte@lists.debian.org, debian-devel@lists.debian.org
Subject: Re: Technical Committee: decision on #119517?
Date: Sat, 20 Apr 2002 22:11:30 -0500
[Message part 1 (text/plain, inline)]
Hi,

        From reviewing the bug report, Ian Jackson sided with the
 maintainer, with the opinion that not all binaries shipped with a
 package need work when the dependencies are satisfied. Dale Scheetz,
 Jason Gunthorpe, and I disagreed. 

	The suggestion was to either:
 a) split off cardinfo and declare the X libraries in the Depends:
    field, or
 b) keep it in the current package and include the X libraries in the
    Depends: field. 
 c) Create a wrapper for cardinfo that provides information on the
    current set of cards on stdout, and in the presence of a DISPLAY
    variable provides additional, X based functionality,

	I suggest that the quorum of two was met, and that the
 decision of the committee be formalized.

	manoj
-- 
 Most people have two reasons for doing anything -- a good reason, and
 the real reason.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and filed, but not forwarded. Copy sent to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #290 received at 119517-quiet@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Branden Robinson <branden@debian.org>
Cc: 119517-quiet@bugs.debian.org, debian-ctte@lists.debian.org,
Subject: Re: Technical Committee: decision on #119517?
Date: Fri, 26 Apr 2002 22:34:23 +0100
Branden Robinson writes ("Technical Committee: decision on #119517?"):
> Over six months ago, on 2001-11-14, Bug #119517 was submitted to the
> Technical Committee for a ruling.  No member of the Technical Committe
> has participated in any public discussion of this bug (at least in the
> bug logs or in available messages from the debian-ctte list archives)
> since 2001-12-04, and no apparently discussion of any sort since
> 2002-02-26.

Apologies for the delay.  I've been the chairman of the committee
since the end of January and have, unfortunately, let it slide.  I'm
now rearranging my schedule to prevent that.

> Does the Technical Committee have any plans to issue any statement on
> this issue?  Either an affirmative statement regarding the issue on
> point, or a statement that the Committee refuses to countenance the
> it?  If the latter, please provide some reasoning as to why, as Section
> 6.3.6 of the Constitution appears to be applicable:

It is our job and we will get back to you.  I hope to have a formal
answer within no more than 4 weeks.

Ian.



Information forwarded to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and filed, but not forwarded. Copy sent to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #295 received at 119517-quiet@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: Ian Jackson <ian@davenant.greenend.org.uk>
Cc: 119517-quiet@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Technical Committee: decision on #119517?
Date: Wed, 19 Jun 2002 00:18:12 -0500
[Message part 1 (text/plain, inline)]
On Fri, Apr 26, 2002 at 10:34:23PM +0100, Ian Jackson wrote:
> Apologies for the delay.  I've been the chairman of the committee
> since the end of January and have, unfortunately, let it slide.  I'm
> now rearranging my schedule to prevent that.
[...]
> It is our job and we will get back to you.  I hope to have a formal
> answer within no more than 4 weeks.

Well, it's been over 7 weeks, by my count (as observed before, sometimes
my math gets fuzzy when I attempt to work with dates :) ).

Do you have any information or status regarding the pending issues
before the Committee?

-- 
G. Branden Robinson                |    There is no housing shortage in
Debian GNU/Linux                   |    Lincoln today -- just a rumor that
branden@debian.org                 |    is put about by people who have
http://people.debian.org/~branden/ |    nowhere to live.    -- G. L. Murfin
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and filed, but not forwarded. Copy sent to tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #300 received at 119517-quiet@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Branden Robinson <branden@debian.org>
Cc: 119517-quiet@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Mon, 24 Jun 2002 00:10:00 +0100
The current state of this seems to be:

* Everyone agrees that it's not ideal for programs to fail in this
way.  There is disagreement about whether it should be always strictly
forbidden in every case, or whether there are other tradeoffs
etc. that might justify it.  (I can't quite make out whether Anthony
and Manoj are really saying that a strict rule should be made.)

* Anthony and Manoj feel that cardinfo should be split.  I feel that
it should remain the same.

* No-one else on the committee has said anything else of substance.

To overrule a developer requires a 3:1 supermajority, which is not
currently apparently available.  I was hoping that some of the other
TC members would comment, but it seems they're all apathetic.

We haven't ever been here before, but it seems to me that the best
course of action would be to formulate a resolution overruling the
pcmcia-cs maintainer's decision and vote on it.  If it fails, we have
at least cleared the question off our books.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #305 received at 119517@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: debian-ctte@lists.debian.org, 119517@bugs.debian.org, 119517-submitter@bugs.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Fri, 28 Jun 2002 19:19:59 +0100
Ian Jackson writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package"):
> We haven't ever been here before, but it seems to me that the best
> course of action would be to formulate a resolution overruling the
> pcmcia-cs maintainer's decision and vote on it.  If it fails, we have
> at least cleared the question off our books.

No-one has objected, so we should take this route.

I therefore hereby propose the following two alternative versions of a
resolution for this issue:

 Version A (my favourite):

  1. It is generally bad for programs to fail due to run-time
     linkage failures, in most cases.  There may however be other
     tradeoffs involved that make this a reasonable choice.

  2. In this particular case, splitting the package introduces a level
     of administration and other overhead which outweighs the minor
     ugliness of the run-time linker error message.

  3. We therefore agree with the package maintainer that pcmcia-cs
     should remain one package, with cardinfo included.

  4. The bug report should be closed with no action.

 Version B (Anthony and Manoj, I think):

  1. It is generally bad for programs to fail due to run-time
     linkage failures, in most (if not all) cases.

  2. In this particular case there are no countervailing tradeoffs
     that legitimise the behaviour.  In particular, the alternative
     solution of splitting the package has no significant problems
     that are relevant.

  3. We therefore agree with the submitter that pcmcia-cs should be
     split, with cardinfo being put into a separate binary.  We
     recommend or direct that the maintainer do so.

  4. The bug report should be reassigned to the pcmcia-cs package.

I hope I've captured everyone's opinions, and the substance of our
disagreement, accurately.  If not, please propose an amendment to
version A or B, or at least complain and I'll try to draft it for you.

If the wordings seem good, I'll call for a vote.

Ian.



Message sent on to Branden Robinson <branden@debian.org>:
Bug#119517. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org:
Bug#119517; Package tech-ctte,pcmcia-cs. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>, Brian Mays <brian@debian.org>, tech-ctte@packages.qa.debian.org, pcmcia-cs@packages.qa.debian.org. Full text and rfc822 format available.

Message #313 received at 119517@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: debian-ctte@lists.debian.org, 119517@bugs.debian.org, 119517-close@bugs.debian.org, 119517-submitter@bugs.debian.org, pcmcia-cs@packages.debian.org
Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Date: Fri, 19 Jul 2002 20:16:15 +0100
For history of this resolution, see earlier postings on the tech ctte
list.  The committee has voted as follows:
   Bdale     FD, B, A
   Ian       A, FD, B
   Manoj     B, FD, A
   Wichert   A, FD, B
   Dale      no response
   Guy       no response
   Jason     no response
   Raul      no response

The result of this a tie between A and FD.  I hereby use my casting
vote as Chairman to resolve the tie in favour of A.  For full details
of how the vote is counted, see below.  I'll respond separately to the
points people have made alongside their votes, to try to keep this
this results message as short as it can be.

Therefore, the Technical Committee has passed the following
resolution:

  1. It is generally bad for programs to fail due to run-time
     linkage failures, in most cases.  There may however be other
     tradeoffs involved that make this a reasonable choice.

  2. In this particular case, splitting the package introduces a level
     of administration and other overhead which outweighs the minor
     ugliness of the run-time linker error message.

  3. We therefore agree with the package maintainer that pcmcia-cs
     should remain one package, with cardinfo included.

  4. The bug report should be closed with no action.

I am closing the bug report with this message and will update the
committee webpages.

Thanks to everyone for participating and for generally managing to
keep the conversation civilised despite strong feelings (which I think
are fair enough even if I disagree with the content).

Ian.


Vote counting
-------------

Firstly - constitution A.3(1) - we select either A or B as the `most
preferred form' (henceforth P), or choose FD.  This is to be done by
the Condorcet method from A.6 (misspelled Concorde in the
constitution).

First, we calculate which options dominate others according to A.6(2):

 Ballots	A to FD	 Ian, Wichert
  which prefer	FD to A	 Manoj, Bdale	neither FD nor A dominates

		FD to B	 Ian, Wichert, Bdale
		B to FD	 Manoj		FD dominates B

		A to B	 Ian, Wichert
		B to A	 Manoj, Bdale	neither A or B dominates

So according to A.6(3) we eliminate B because it is dominated by FD.

This leaves us with a choice between FD and B, and the ballots have
decayed to  A, FD (Wichert, Ian)  and  FD, A (Manoj, Bdale).  This is
a tie, which my casting vote resolves.

(Other interpretations of the counting system have similar results.)


Secondly - constitution A.3(2) - we decide whether the most preferred
form A beats FD by enough to pass.  Again, we have the same two pairs
of ballots:  Yes, No/FD (Wichert, Ian)  and  No/FD (Manoj, Bdale).
Again I use my casting vote again to make Yes win.

Thirdly, according to A.6(8) we check for the quorum, which is two
according to 6.3(1).  There were at least two votes which prefer the
winning option (A) to the default option (FD), so the quorum is
reached.

-- 
Ian Jackson, at home.           Local/personal: ijackson@chiark.greenend.org.uk
ian@davenant.greenend.org.uk       http://www.chiark.greenend.org.uk/~ijackson/



Reply sent to Ian Jackson <ian@davenant.greenend.org.uk>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Branden Robinson <branden@debian.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message sent on to Branden Robinson <branden@debian.org>:
Bug#119517. Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 10:40:08 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.