[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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 pack
ages 
> define Recommends and Suggests on specific other packages.
> 
> My problem with the current situation that you either do the policy of alw
ays 
> 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 complet
ely 
> mysterious to me. And even after installation, I still don't know how thos
e 
> additional packages do extend/improve/whatever the originally wanted packa
ge.
> 
> It would be nice if maintainers of packages with Recommends and Suggests t
hat 
> are non-obvious could state in the package description a reason for each o
f 
> 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 _______|

[ Post a follow-up to this message ]

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 brows
er]
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Thu, 17 May 2007 11:29:16 +0200
Hendrik Sattler <debian@hendrik-sattler.de> wrote:

> Hi,
>
> what I am really missing in the current dependency scheme is WHY some pack
ages
> 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 alw
ays
> 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 complet
ely
> 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.[/vbc
ol]

That isn't a problem - when you want to use a particular feature, the
manpage should provide the info you need.
[vbcol=seagreen]
> It would be nice if maintainers of packages with Recommends and Suggests t
hat
> are non-obvious could state in the package description a reason for each o
f
> 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/

[ Post a follow-up to this message ]

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 brows
er]
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Thu, 17 May 2007 19:53:07 +0200 (CEST)
"Thijs Kinkhorst" <thijs@debian.org> wrote:

> On Thu, May 17, 2007 11:58, Kevin Mark wrote: 
>
> 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: 
>
> 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/

[ Post a follow-up to this message ]

On Thu, 17 May 2007 20:48:57 +0200
"Steinar H. Gunderson" <sgunderson@bigfoot.com> wrote:

> On Thu, May 17, 2007 at 07:43:09PM +0100, Neil Williams wrote: 
>
> 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/

[ Post a follow-up to this message ]

On Thu, May 17, 2007 at 07:53:07PM +0200, Thijs Kinkhorst wrote:
> On Thu, May 17, 2007 11:58, Kevin Mark wrote: 
>
> 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: 
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]