Reasons for recommends and suggests

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Reasons for recommends and suggests

Hendrik Sattler-4
Hi,

what I am really missing in the current dependency scheme is WHY some packages
define Recommends and Suggests on specific other packages.

My problem with the current situation that you either do the policy of always
installing such stuff or you don't. There is no way to decide case by case
because there is definitely information missing in the description of
packages.

OK, some of those are obvious but some Recommends and Suggests are completely
mysterious to me. And even after installation, I still don't know how those
additional packages do extend/improve/whatever the originally wanted package.

It would be nice if maintainers of packages with Recommends and Suggests that
are non-obvious could state in the package description a reason for each of
them.

If I file bugs about them, which severity can this be given?

HS

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Frans Pop-3
On Thursday 17 May 2007 11:29, Hendrik Sattler wrote:
> If I file bugs about them, which severity can this be given?

I'd say wishlist.

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Kevin Mark-6
In reply to this post by Hendrik Sattler-4
On Thu, May 17, 2007 at 11:29:16AM +0200, Hendrik Sattler wrote:

> Hi,
>
> what I am really missing in the current dependency scheme is WHY some packages
> define Recommends and Suggests on specific other packages.
>
> My problem with the current situation that you either do the policy of always
> installing such stuff or you don't. There is no way to decide case by case
> because there is definitely information missing in the description of
> packages.
>
> OK, some of those are obvious but some Recommends and Suggests are completely
> mysterious to me. And even after installation, I still don't know how those
> additional packages do extend/improve/whatever the originally wanted package.
>
> It would be nice if maintainers of packages with Recommends and Suggests that
> are non-obvious could state in the package description a reason for each of
> them.
>
> If I file bugs about them, which severity can this be given?
What I thought about a while ago was this:
---------------
Package: mutt
Suggests: ispell [adds spell cheking while composing emails]
Suggests: urlview [extracts urls from email and can lanuch a web browser]
Suggests: mixmaster [allows you to compose anonymized email]
-------------
I'd see the maintainer create (or a user contribute)  a 'short
description' to accompany each suggest and recommends that is displayed
$SOMEWHERE.  So that the user can not just see a list of suggestions but
a real reason as to why you'd want to install them.
--
|  .''`.  == Debian GNU/Linux == |       my web site:           |
| : :' :      The  Universal     |mysite.verizon.net/kevin.mark/|
| `. `'      Operating System    | go to counter.li.org and     |
|   `-    http://www.debian.org/ |    be counted! #238656       |
|  my keyserver: subkeys.pgp.net |     my NPO: cfsg.org         |
|join the new debian-community.org to help Debian!              |
|_______  Unless I ask to be CCd, assume I am subscribed _______|

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Loïc Minier
On Thu, May 17, 2007, Kevin Mark wrote:

> What I thought about a while ago was this:
> ---------------
> Package: mutt
> Suggests: ispell [adds spell cheking while composing emails]
> Suggests: urlview [extracts urls from email and can lanuch a web browser]
> Suggests: mixmaster [allows you to compose anonymized email]
> -------------
> I'd see the maintainer create (or a user contribute)  a 'short
> description' to accompany each suggest and recommends that is displayed
> $SOMEWHERE.  So that the user can not just see a list of suggestions but
> a real reason as to why you'd want to install them.

 I find your proposed extension of the format of control headers very
 inspiring; perhaps it makes sense to spec an extension to this format
 to permit various transversal information to be stored.

 Other header based formats/protocols such as HTTP or RFC 2822 permit
 things like:

    Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx"
 or:

    Content-Type: text/html; charset=iso-8859-1

 but I don't see any similar way of attaching meta-information to lists
 in a single header; your solution would be one (which is already used
 for architecture information unfortunately), another one could be:

    Suggests: mixmaster?description="allows%20anonymizing%20emails",
        urlview?description="extracts%20urls%20from%20email"&priority=10

--
Loïc Minier


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Neil Williams-2
In reply to this post by Hendrik Sattler-4
On Thu, 17 May 2007 11:29:16 +0200
Hendrik Sattler <[hidden email]> wrote:

> Hi,
>
> what I am really missing in the current dependency scheme is WHY some packages
> define Recommends and Suggests on specific other packages.

I use Recommends or Suggests when the package includes a variety of
scripts with broadly related purposes. The main Depends: line is
determined by a "core" set of scripts (which may be described in detail
in the long description) but if there are a couple of optional scripts
that some people may like to use but which aren't strictly essential to
the use of the package, then those dependencies get put into Recommends
or Suggests.

The meaning, to me, is:

Recommends: needed or useful in conjunction with optional or limited
usage scenarios where alternative methods may exist.

Suggests: Not a strict dependency of any script in the package, just
useful for helping the user find their way around the package. e.g.
dwww for docs.

> My problem with the current situation that you either do the policy of always
> installing such stuff or you don't. There is no way to decide case by case
> because there is definitely information missing in the description of
> packages.

You install a Recommends or Suggests when you want to use some part of
the package that uses it. The obvious place to document such
requirements is the manpage for the optional script. In most cases,
users simply don't need to use those options.

e.g. emdebian-tools Recommends subversion because although the "core"
emdebian-tools scripts can be used without subversion, there is an
optional script which requires subversion. Not everyone using
emdebian-tools needs to use the optional script (emsource) because
emsource is a cross-build-aware wrapper for 'apt-get source' that also
manages the Emdebian SVN. If you aren't using the Emdebian SVN,
emsource is of little use to you. Making subversion a dependency of
emdebian-tools would be pointless. Having said that, emsource is
becoming more like a core script and a later release may deprecate
using apt-get source directly and migrate emsource into the "core".

> OK, some of those are obvious but some Recommends and Suggests are completely
> mysterious to me.

Until you use the package and come up against the one area where the
Recommended package is actually useful, this is to be expected. Until
you need to use that one option, there is no need for you to be
concerned. At the point where you need that option, the manpage for
that script or program should explain the role of the recommended
package.

> And even after installation, I still don't know how those
> additional packages do extend/improve/whatever the originally wanted package.

That isn't a problem - when you want to use a particular feature, the
manpage should provide the info you need.

> It would be nice if maintainers of packages with Recommends and Suggests that
> are non-obvious could state in the package description a reason for each of
> them.

Package descriptions can be long enough as it is - IMHO the best place
for this information is the manpage. Things like "Recommends" often
needs context - the reason for using the recommended package needs to
be explained in relation to the rest of the scripts and the overall
purpose of the package. There is no room to do that in the description.

> If I file bugs about them, which severity can this be given?

wontfix.
;-)

The location of this information should be the manpage, IMHO. Moreover,
it should be the manpage of the specific program/script that uses or
is related to the recommended package.

The only bug suitable for this scenario is a wishlist bug for a more
verbose manpage.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Thijs Kinkhorst-4
On Thu, May 17, 2007 11:58, Kevin Mark wrote:
> Package: mutt
> Suggests: ispell [adds spell cheking while composing emails]
> Suggests: urlview [extracts urls from email and can lanuch a web browser]
> Suggests: mixmaster [allows you to compose anonymized email]

This seems like a useful idea to me. As a technical detail, I'd use '('
and ')' because those are used for optional comments in the RFC822 format
already.

On Thu, May 17, 2007 19:22, Neil Williams wrote:
> The only bug suitable for this scenario is a wishlist bug for a more
> verbose manpage.

It seems cumbersome to me to be presented with a list of recommends and
suggests at install time, ignore that and finish install, read the manpage
and then go back to the package manager to install extra packages. I'd
rather just make that decision when I'm at the root prompt anyway.


Thijs


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Neil Williams-2
On Thu, 17 May 2007 19:53:07 +0200 (CEST)
"Thijs Kinkhorst" <[hidden email]> wrote:

> On Thu, May 17, 2007 11:58, Kevin Mark wrote:
> > Package: mutt
> > Suggests: ispell [adds spell cheking while composing emails]
> > Suggests: urlview [extracts urls from email and can lanuch a web browser]
> > Suggests: mixmaster [allows you to compose anonymized email]
>
> This seems like a useful idea to me. As a technical detail, I'd use '('
> and ')' because those are used for optional comments in the RFC822 format
> already.

() are used for dependencies in other control fields - I would see '('
as a recipe for confusion.

> On Thu, May 17, 2007 19:22, Neil Williams wrote:
> > The only bug suitable for this scenario is a wishlist bug for a more
> > verbose manpage.
>
> It seems cumbersome to me to be presented with a list of recommends and
> suggests at install time, ignore that and finish install, read the manpage
> and then go back to the package manager to install extra packages. I'd
> rather just make that decision when I'm at the root prompt anyway.

? sudo ?

Most users don't need to use the packages given as Recommends or
Suggests so the purpose, as I see it, is to help those who have unusual
or extended needs for the functions provided by the package. Are you
likely to know whether this is appropriate until you've had a chance to
use the package?

BTW: read which manpage? My example is from a package that is a
toolset. Out of the collection, only one script needs subversion right
now. There are multiple manpages in the package - only one describes
the role of subversion. Understanding whether you need that
functionality requires context - you cannot necessarily decide upon a
crude one-liner.

Take another package of mine: pilot-qof.

Recommends: libqof-backend-sqlite0, datafreedom-qsfxsl, datafreedom-perl
Suggests: datafreedom-doc

To me, the purpose of these two lines is simple: highlight that these
packages are related to pilot-qof in some way. If the user wants to
find out more, man pilot-qof is the only sensible option because the
purpose of each recommendation or suggestion needs to be explained
within the context of what the package itself can actually achieve.

Over-simplification doesn't do anyone any favours - it can promote
something that the package cannot do or it can omit something that the
package can do. Some things just need to be explained in detail,
within the overall context of the relevant packages. That is one of the
purposes of a manpage, IMHO. To let the user find out "How do I use X?"

In turn: datafreedom-qsfxsl:
Recommends: pilot-qof, gpe-expenses, zenity, datafreedom-doc
Suggests: calcurse, dlume, dates, contacts, gpe-contacts, gpe-calendar

These are some of the applications that can import or convert data
converted by the XSL within the package or are used by scripts based on
the XSL in some way.

Full details of what fits where and when one package is recommended
over another from the same list cannot be contained within an
over-simplified one-liner. These details are in the manpage(s) and
further documented in the suggested -doc package.

It's my way of saying that if you use any of the suggested packages,
some of the recommended packages can be used to share data with the
applications that you actually use. None are essential, I doubt that
anyone, except me, has all of the recommended and suggested packages
installed. You cannot sensibly make the choice until you've tried out
the package and decided which other package and which scripts best fit
your needs.

This problem is common to all kinds of toolset, conversion,
inter-operability and data synchronisation packages.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Steinar H. Gunderson
On Thu, May 17, 2007 at 07:43:09PM +0100, Neil Williams wrote:
> Most users don't need to use the packages given as Recommends or
> Suggests so the purpose, as I see it, is to help those who have unusual
> or extended needs for the functions provided by the package.

You are at odds with Policy with regard to most users and Recommends here,
as I read it. Section 7.2:

     `Recommends'
          This declares a strong, but not absolute, dependency.

          The `Recommends' field should list packages that would be found
          together with this one in all but unusual installations.

In other words, most users _will_ need to use the packages given as
Recommends (which is why aptitude installs them by default). Suggests is a
completely different game, though.

/* Steinar */
--
Homepage: http://www.sesse.net/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Neil Williams-2
On Thu, 17 May 2007 20:48:57 +0200
"Steinar H. Gunderson" <[hidden email]> wrote:

> On Thu, May 17, 2007 at 07:43:09PM +0100, Neil Williams wrote:
> > Most users don't need to use the packages given as Recommends or
> > Suggests so the purpose, as I see it, is to help those who have unusual
> > or extended needs for the functions provided by the package.
>
> You are at odds with Policy with regard to most users and Recommends here,

Yes, I should have phrased that better - I was glossing over the
difference between Recommends and Suggests. I've reviewed one or two of
the packages and migrated some existing Recommends to Suggests, also
migrated some current Suggest to an Enhances: in the other package
(where that package is one of my own). (So that's 'pending'.)

>           The `Recommends' field should list packages that would be found
>           together with this one in all but unusual installations.

That's then perfect for emdebian-tools recommending subversion.

> In other words, most users _will_ need to use the packages given as
> Recommends (which is why aptitude installs them by default).

I didn't know that. Thanks for the tip, it could be a problem with an
embedded version of aptitude - many package maintainers would consider
a cross-build to be an unusual installation.  ;-)

Emdebian may need to tinker with the Recommends: of cross-built
packages to retain a sane dependency tree. I'll have to make a note of
that.

I'm still not convinced that such relationships can be accurately
summarised in a control line devoid of context.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Kevin Mark-6
In reply to this post by Thijs Kinkhorst-4
On Thu, May 17, 2007 at 07:53:07PM +0200, Thijs Kinkhorst wrote:

> On Thu, May 17, 2007 11:58, Kevin Mark wrote:
> > Package: mutt
> > Suggests: ispell [adds spell cheking while composing emails]
> > Suggests: urlview [extracts urls from email and can lanuch a web browser]
> > Suggests: mixmaster [allows you to compose anonymized email]
>
> This seems like a useful idea to me. As a technical detail, I'd use '('
> and ')' because those are used for optional comments in the RFC822 format
> already.
>
> On Thu, May 17, 2007 19:22, Neil Williams wrote:
> > The only bug suitable for this scenario is a wishlist bug for a more
> > verbose manpage.
>
> It seems cumbersome to me to be presented with a list of recommends and
> suggests at install time, ignore that and finish install, read the manpage
> and then go back to the package manager to install extra packages. I'd
> rather just make that decision when I'm at the root prompt anyway.
>
I agree. There are different users, not all are 'programmers', some are
gui-desktop-users ( and as such should not be ignored and expect only
'programmers' to be using your programs)  and all they want to know is
<<how will this 'suggest'ed program enhance my program>>. If you are using
synaptic or aptitude and just about to select evolution to install it
and want to connect to exchange then you should not have to first know
how to install and configure an exchange server, read all its manuals,
then read all of evolutions documentation and man pages just to know
that you need to add 'evolution-exchange' to your selection on the
synaptic or aptitude screen before you install them. Also, not every
package should be required to add these descriptions as the
'programmer'-users will either already know what to install or will in
fact read all the man pages and thus find out what to install.
--
|  .''`.  == Debian GNU/Linux == |       my web site:           |
| : :' :      The  Universal     |mysite.verizon.net/kevin.mark/|
| `. `'      Operating System    | go to counter.li.org and     |
|   `-    http://www.debian.org/ |    be counted! #238656       |
|  my keyserver: subkeys.pgp.net |     my NPO: cfsg.org         |
|join the new debian-community.org to help Debian!              |
|_______  Unless I ask to be CCd, assume I am subscribed _______|


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Brian May-8
In reply to this post by Neil Williams-2
>>>>> "Neil" == Neil Williams <[hidden email]> writes:

    Neil> The only bug suitable for this scenario is a wishlist bug
    Neil> for a more verbose manpage.

I want to know if I should install the package recommendations or not
when I install the package.

Unfortunately you cannot see the man pages until after the package is
installed. Also aptitude will by default install all recommendations.

Sometimes recommendations include packages that appear to be
excessive. Do I really need to install the kernel source to get this
package working? Maybe not (sorry can't remember the package that did
this now). Other times the recommendations will conflict with other
things I have installed.

I want to know at the time of installing a new kernel, in aptitude,
for example, if and why I should allow aptitude to continue its
favoured approach to install the recommended libc6-i686 and remove the
conflicting libc6-xen package.

Anybody who knows xen would also know that I should keep libc6-xen,
but there are lots of cases when I am just trying out a new package
for the first time and I don't yet know what features I will need or
not need.

This in turn can result in errors when experimenting with new packages
where it is not immediately obvious it is due to a package that is not
installed that perhaps should be.
--
Brian May <[hidden email]>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Felipe Sateler
In reply to this post by Neil Williams-2
Neil Williams wrote:

> You install a Recommends or Suggests when you want to use some part of
> the package that uses it. The obvious place to document such
> requirements is the manpage for the optional script. In most cases,
> users simply don't need to use those options.

Recommends/Suggests aren't only for stuff required for specific scripts
inside a package, and it's not always that obvious that a script or program
may require extra libs. For example, I still wonder why the hell
openoffice.org-core recommends nfs-common.

--

  Felipe Sateler


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Don Armstrong
In reply to this post by Brian May-8
On Fri, 18 May 2007, Brian May wrote:
> >>>>> "Neil" == Neil Williams <[hidden email]> writes:
>
>     Neil> The only bug suitable for this scenario is a wishlist bug
>     Neil> for a more verbose manpage.
>
> I want to know if I should install the package recommendations or not
> when I install the package.

The recommends should be a set such that you'd want to install them,
unless you know specifically why you don't. [In the majority of cases
that I've personally run into, this means "unusual" setups like a
separate database server, stripped installs, etc.]

Moreover, the information necessary to explain what packages that are
Recommends: or Suggests: actually do and the additional features they
require is not something that can be easily jammed into the
Description without making the description uselessly long. The
Description should give you enough information to figure out whether
or not you want to install a package, not telling you how to use the
package or the descriptions of other packages that the package
Recommends: or Suggests:. That kind of documentation really belongs in
README.Debian or other documentation included with the package.


Don Armstrong

--
All bad precedents began as justifiable measures.
 -- Gaius Julius Caesar in "The Conspiracy of Catiline" by Sallust

http://www.donarmstrong.com              http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Daniel Burrows
In reply to this post by Neil Williams-2
On Thu, May 17, 2007 at 06:22:11PM +0100, Neil Williams <[hidden email]> was heard to say:

> On Thu, 17 May 2007 11:29:16 +0200
> Hendrik Sattler <[hidden email]> wrote:
> > My problem with the current situation that you either do the policy of always
> > installing such stuff or you don't. There is no way to decide case by case
> > because there is definitely information missing in the description of
> > packages.
>
> You install a Recommends or Suggests when you want to use some part of
> the package that uses it. The obvious place to document such
> requirements is the manpage for the optional script. In most cases,
> users simply don't need to use those options.

  When aptitude displays its list of "here's what I'll do", there's
a section for packages being automatically installed, and one for
recommended/suggested packages that are not being installed.  Right
now it says things like:

    foo recommends bar (>= 1.2.3)

  I would really like to have it say:

    foo recommends bar (>= 1.2.3) to frobnicate the whazzit.

  My thought on this topic has been to do something like:

Recommends-Reason: bar (>= 1.2.3); to frobnicate the whazzit.
 

  These fields would be purely decorative, so they could be ignored by
the core algorithms (no need to rewrite dpkg's Depends parsing).  They
also don't clutter up the Depends line, which is IMO likely to be
important if you're just trying to read through the dependencies.

  My general feeling is that these would be unlikely to have enough
uptake to justify implementing them...but if a patch were to drop from
heaven (or I suddenly found that I had a week of free time, hah) I
would be happy to give it a shot.

  Daniel


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Hendrik Sattler-4
In reply to this post by Don Armstrong
Am Freitag 18 Mai 2007 01:56 schrieb Don Armstrong:

> The recommends should be a set such that you'd want to install them,
> unless you know specifically why you don't. [In the majority of cases
> that I've personally run into, this means "unusual" setups like a
> separate database server, stripped installs, etc.]
>
> Moreover, the information necessary to explain what packages that are
> Recommends: or Suggests: actually do and the additional features they
> require is not something that can be easily jammed into the
> Description without making the description uselessly long. The
> Description should give you enough information to figure out whether
> or not you want to install a package, not telling you how to use the
> package or the descriptions of other packages that the package
> Recommends: or Suggests:. That kind of documentation really belongs in
> README.Debian or other documentation included with the package.
The description should not explain what the other package is but _what_ it
does to the selected package.
Example: ucf recommends debconf-utils. The description of debconf-utils tells
me nothing about what it actually does (really could be more verbose) and I
cannot draw the connection line to ucf. The question that arises is: "Do I
also need it if I am not a debconf developer?".
I would say no based on the description of debconf-utils just because I have
not the faintest idea what ucf does with those. And no, I do not want to read
all manpages and README.Debian files for packages that maybe are 4th-level
dependencies of a selected package (although I look at all of them in
aptitude).

HS

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Don Armstrong
On Fri, 18 May 2007, Hendrik Sattler wrote:
> The description should not explain what the other package is but
> _what_ it does to the selected package.

In order to explain what the recommended package does to the
recommeding package, you have to explain what the other package is to
some extent.

> Example: ucf recommends debconf-utils. The description of debconf-utils tells
> me nothing about what it actually does (really could be more verbose) and I
> cannot draw the connection line to ucf. The question that arises is: "Do I
> also need it if I am not a debconf developer?".

My point is that you shouldn't care in the default case, at least for
Recommends. The only time you wouldn't want a Recommends: installed is
if you know that it wouldn't be useful.

Anyone who cares should know to look in README.Debian to find it out;
those who don't know enough wouldn't be able to make a decision based
on a tiny blurb in the Description anyway.

For example, in the case you're talking about, you'd have to explain
that ucf would like to be able to use debconf-loadtemplate from
debconf-utils utils when it's running as root just in case its
templates have become corrupted. Now, you and I may know what
debconf-loadtemplate does, what a template is, and why ucf would be
worried about corruption of its template database, but I can't imagine
making this intelligible to even an intermediate Debian user in less
than 5 lines. Hell, I took 3 lines here to say something about it that
I only understand because I read /usr/bin/ucf.

> And no, I do not want to read all manpages and README.Debian files
> for packages that maybe are 4th-level dependencies of a selected
> package (although I look at all of them in aptitude).

So an incomplete, terse phase in the Description which is opaque to
most people who don't read this list is better than actual
documentation in the README.Debian? I disagree, and frankly, I don't
plan on documenting the few packages I have that Recommend: other
things outside of the README.Debian or manpages where appropriate.


Don Armstrong

--
"People selling drug paraphernalia ... are as much a part of drug
trafficking as silencers are a part of criminal homicide."
 -- John Brown, DEA Chief

http://www.donarmstrong.com              http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Kevin Mark-6
On Fri, May 18, 2007 at 02:04:24AM -0700, Don Armstrong wrote:

> On Fri, 18 May 2007, Hendrik Sattler wrote:
> > The description should not explain what the other package is but
> > _what_ it does to the selected package.
>
> In order to explain what the recommended package does to the
> recommeding package, you have to explain what the other package is to
> some extent.
>
> > Example: ucf recommends debconf-utils. The description of debconf-utils tells
> > me nothing about what it actually does (really could be more verbose) and I
> > cannot draw the connection line to ucf. The question that arises is: "Do I
> > also need it if I am not a debconf developer?".
>
> My point is that you shouldn't care in the default case, at least for
> Recommends. The only time you wouldn't want a Recommends: installed is
> if you know that it wouldn't be useful.
>
> Anyone who cares should know to look in README.Debian to find it out;
> those who don't know enough wouldn't be able to make a decision based
> on a tiny blurb in the Description anyway.
>
> For example, in the case you're talking about, you'd have to explain
> that ucf would like to be able to use debconf-loadtemplate from
> debconf-utils utils when it's running as root just in case its
> templates have become corrupted. Now, you and I may know what
> debconf-loadtemplate does, what a template is, and why ucf would be
> worried about corruption of its template database, but I can't imagine
> making this intelligible to even an intermediate Debian user in less
> than 5 lines. Hell, I took 3 lines here to say something about it that
> I only understand because I read /usr/bin/ucf.
>
> > And no, I do not want to read all manpages and README.Debian files
> > for packages that maybe are 4th-level dependencies of a selected
> > package (although I look at all of them in aptitude).
>
> So an incomplete, terse phase in the Description which is opaque to
> most people who don't read this list is better than actual
> documentation in the README.Debian? I disagree, and frankly, I don't
> plan on documenting the few packages I have that Recommend: other
> things outside of the README.Debian or manpages where appropriate.
>
As I mentioned, I dont think this information should be in every
package and probably would be useful for more desktop-users than
developers. I'd only suggest creating the infrastructure (presumably so
that it doesn't break anything in dpkg and would only be shown in
aptitude and synaptic) and then allow either the maintainer to add it or
allow users to contribute to it.
--
|  .''`.  == Debian GNU/Linux == |       my web site:           |
| : :' :      The  Universal     |mysite.verizon.net/kevin.mark/|
| `. `'      Operating System    | go to counter.li.org and     |
|   `-    http://www.debian.org/ |    be counted! #238656       |
|  my keyserver: subkeys.pgp.net |     my NPO: cfsg.org         |
|join the new debian-community.org to help Debian!              |
|_______  Unless I ask to be CCd, assume I am subscribed _______|

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Don Armstrong
On Fri, 18 May 2007, Kevin Mark wrote:
> As I mentioned, I dont think this information should be in every
> package and probably would be useful for more desktop-users than
> developers. I'd only suggest creating the infrastructure (presumably so
> that it doesn't break anything in dpkg and would only be shown in
> aptitude and synaptic) and then allow either the maintainer to add it or
> allow users to contribute to it.

It would probably be enough then to just have it available in
README.Debian and modify the p.d.o changelogs script to also extract
README.Debian when it exists; allowing aptitude/synaptic et al. to
show README.Debian like changelogs are shown now.

This would allow explanations of appropriate length about the packages
which are Recommends: and Suggests: (or anything else that people ask
about) as well as any additional information that users may want to
know about before installing.

Plus, you'd have the advantage of being able to do this now instead of
trying to jam more information into the control file which doesn't
strictly need to be there.


Don Armstrong

--
The attackers hadn't simply robbed the bank. They had carried off
everything portable, including the security cameras, the carpets, the
chairs, and the light and plumbing fixtures. The conspirators had
deliberately punished the bank, for reasons best known to themselves,
or to their unknown controllers. They had superglued doors and
shattered windows, severed power and communications cables, poured
stinking toxins into the wallspaces, and concreted all of the sinks
and drains. In eight minutes, sixty people had ruined the building so
thouroughly that it had to be condemed and later demolished.
 -- Bruce Sterling, _Distraction_ p4

http://www.donarmstrong.com              http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

paddy-9
On Fri, May 18, 2007 at 02:37:06AM -0700, Don Armstrong wrote:

> On Fri, 18 May 2007, Kevin Mark wrote:
> > As I mentioned, I dont think this information should be in every
> > package and probably would be useful for more desktop-users than
> > developers. I'd only suggest creating the infrastructure (presumably so
> > that it doesn't break anything in dpkg and would only be shown in
> > aptitude and synaptic) and then allow either the maintainer to add it or
> > allow users to contribute to it.
>
> It would probably be enough then to just have it available in
> README.Debian and modify the p.d.o changelogs script to also extract
> README.Debian when it exists; allowing aptitude/synaptic et al. to
> show README.Debian like changelogs are shown now.
>
> This would allow explanations of appropriate length about the packages
> which are Recommends: and Suggests: (or anything else that people ask
> about) as well as any additional information that users may want to
> know about before installing.
>
> Plus, you'd have the advantage of being able to do this now instead of
> trying to jam more information into the control file which doesn't
> strictly need to be there.

does putting the info in the README entail the loss of the kind of
structuring that would make it easy to, for example, programmatically
display just the relevant text for a specific recommends?

IIRC, the case was made that such information is more useful (albeit
perhaps rarely) than the package description sometimes for much the
same usage -- deciding whether to install a package -- so why would
it not merit a place in the same file?  Would there be anything to be
gained from having it in the control file ?

While cramming the info into the kinds of formats that have been
suggested might tend to influence the text inappropraitely, consider
that short descriptions can be used in places that long ones can't.

would it be practical to have both mechanisms and only use the control
file mechanism when it was appropriate ?

I'm not keen on bloating the control file, just interested in the
problem.

Regards,
Paddy


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reasons for recommends and suggests

Joey Hess
In reply to this post by Kevin Mark-6
Kevin Mark wrote:

> I agree. There are different users, not all are 'programmers', some are
> gui-desktop-users ( and as such should not be ignored and expect only
> 'programmers' to be using your programs)  and all they want to know is
> <<how will this 'suggest'ed program enhance my program>>. If you are using
> synaptic or aptitude and just about to select evolution to install it
> and want to connect to exchange then you should not have to first know
> how to install and configure an exchange server, read all its manuals,
> then read all of evolutions documentation and man pages just to know
> that you need to add 'evolution-exchange' to your selection on the
> synaptic or aptitude screen before you install them.
A desktop user is perhaps not the best example, since recommends might
as well be depends to such a user -- they're both things that aptitude
installs when the software is selected. Such a user is also better
served by using the desktop task (which will install evolution-exchange
for them BTW).

Tasksel has the problem that it's still not safe to turn on installation
of all recommends of packages in tasks, because recommends is aparently
overused a lot. Without recommends, tasksel installs a pretty nice
desktop environment; if recommends is turned on, 17% more disk space is
used by the recommended stuff. (#388290) Perhaps a few of those packages
would be useful additions to the regular desktop install, but I have not
yet had the fortitude to go through the list, work out what, and file
bugs on the rest.

Cleaning up the recommends to meet policy seems far more useful than
documenting a bunch of bogus recommends, although the idea of putting
small comments in dependency fields is something I'd much like to see
anyway, especially if it were extended to all fields (including
Build-Dependencies[1]). Comments, after all, can be a very useful thing
from time to time.

--
see shy jo

[1] If you really want to add comments to your build-deps, you can use
    the method debian-installer uses to comment its build-deps with some 100
    lines of comments. We would not be able to keep the insane build deps
    straight without them.

signature.asc (196 bytes) Download Attachment
123