|
Home > Archive > Debian Developers > May 2007 > Reasons for recommends and suggests
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Reasons for recommends and suggests
|
|
| Hendrik Sattler 2007-05-17, 7:17 am |
| | |
| Frans Pop 2007-05-17, 7:17 am |
| 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.
| |
| Kevin Mark 2007-05-17, 7:17 am |
| 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 _______|
| |
| Loïc Minier 2007-05-17, 7:17 am |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Neil Williams 2007-05-17, 7:18 pm |
| 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 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/
| |
| Thijs Kinkhorst 2007-05-17, 7:18 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steinar H. Gunderson 2007-05-17, 7:18 pm |
| 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.org
| |
| Neil Williams 2007-05-17, 7:18 pm |
| 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/
| |
| Neil Williams 2007-05-17, 7:18 pm |
| 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/
| |
| Kevin Mark 2007-05-18, 1:19 am |
| 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.org
| |
| Brian May 2007-05-18, 1:19 am |
| >>>>> "Neil" == Neil Williams <linux@codehelp.co.uk> 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 <bam@snoopy.debian.net>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Don Armstrong 2007-05-18, 1:19 am |
| On Fri, 18 May 2007, Brian May wrote:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Felipe Sateler 2007-05-18, 1:19 am |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Daniel Burrows 2007-05-18, 1:19 am |
| On Thu, May 17, 2007 at 06:22:11PM +0100, Neil Williams <linux@codehelp.co.uk> was heard to say:
> On Thu, 17 May 2007 11:29:16 +0200
> Hendrik Sattler <debian@hendrik-sattler.de> 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.
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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hendrik Sattler 2007-05-18, 7:20 am |
| | |
| Don Armstrong 2007-05-18, 7:20 am |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Kevin Mark 2007-05-18, 7:20 am |
| On Fri, May 18, 2007 at 02:04:24AM -0700, Don Armstrong wrote:
> On Fri, 18 May 2007, Hendrik Sattler wrote:
>
> 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.
>
>
> 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.
>
>
> 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 _______|
| |
| Don Armstrong 2007-05-18, 7:20 am |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| paddy@panici.net 2007-05-18, 1:23 pm |
| On Fri, May 18, 2007 at 02:37:06AM -0700, Don Armstrong wrote:
> On Fri, 18 May 2007, Kevin Mark wrote:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joey Hess 2007-05-18, 1:23 pm |
| 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.
| |
| Felipe Sateler 2007-05-18, 7:18 pm |
| Don Armstrong wrote:
> 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.
But then you could just say: "Useful in case template databases get
corrupted". There is no need to go and explain details. Just a general idea
is useful enough. If I were to read that, then I'd say: "Well, I guess
database corruption means something bad, and I want to recover from that
whenever possible. Lets install debconf-utils." I don't need to know which
specific script is being used, what templates are, why there is a database
of them, and how that database may get corrupted. I just know that
debconf-utils would be useful in case of malfunction. Since malfunction
costs more than bandwidth and disk space, I'll install it.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Don Armstrong 2007-05-19, 1:20 am |
| On Fri, 18 May 2007, paddy@panici.net wrote:
> 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?
Not necessarily if people agreed on a specific way to write such
things. Indeed, it's no different from trying to jam it into the
description, where you still have to have maintainers agreeing on a
specific way to write it.
Don Armstrong
--
Q: What Can a Thoughtful Man Hope for Mankind on Earth, Given the
Experience of the Past Million Years?
A: Nothing.
-- Bokonon _The Fourteenth Book of Bokonon_ (Vonnegut _Cats Cradle_)
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Don Armstrong 2007-05-19, 1:20 am |
| On Fri, 18 May 2007, Felipe Sateler wrote:
> Don Armstrong wrote:
>
> But then you could just say: "Useful in case template databases get
> corrupted". There is no need to go and explain details.
If you're not going to explain what it actually does, why bother
writing it at all? You could just as easily assume that the package
maintainer knows what they're talking about when they mark a package
as Recommends: and assume that it should be actually installed in the
default case.
The information above isn't enough to make a rational decision as to
whether you really need debconf-utils when you've got ucf installed or
not.
Don Armstrong
--
Herodotus says, "Very few things happen at the right time, and the
rest do not happen at all. The conscientious historian will correct
these defects".
-- Mark Twain _A Horse's Tail_
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Philippe Cloutier 2007-05-19, 1:20 am |
| > The only time you wouldn't want a Recommends: installed is
> if you know that it wouldn't be useful.
Not really.
Policy is vague and only specifies that Recommends means that more than
a proportion between 1/2 and 1 of systems consider that the recommended
package's contribution to the recommending package makes the recommended
package worth installing if it isn't already installed. Suppose that
proportion would be 1/2. 1/3 of systems initially without package A
install it when installing package B. Package A should therefore be
suggested by B. 2/3 of systems initially without package C install it
when installing package D. Package C should therefore be recommended by D.
Both systems that have B but not A and those that have B and A have
their reasons. You'll agree that system administrators installing B that
do not know why B suggests A can still want A's contribution to B.
In the same way, both systems that have D but not C and those that have
D and C have their reasons. Administrators installing D that do not know
why D suggests C can still want C's contribution to D.
In practice, the proportion for Recommends is higher than 1/2, but the
same reasoning applies.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Daniel Burrows 2007-05-19, 1:20 am |
| On Thu, May 17, 2007 at 04:56:23PM -0700, Don Armstrong <don@debian.org> was heard to say:
> On Fri, 18 May 2007, Brian May wrote:
>
> 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.]
That's true for recommendations, but suggestions are fully optional,
and providing the user with the information necessary to make an informed
decision would be IMO a very good thing. Recommends come along "for free"
then. :-)
> 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.
That's true. But I would very much be in favor of adding new, optional
fields that describe the dependencies of the package. These can be
integrated into the package management interface at appropriate points,
without cluttering the description itself.
Stuffing information into README.Debian doesn't help, since (a) you
can't read it until you've installed the package, and (b) NLP parsing
isn't good enough to find the text you need and extract it automatically :-).
Daniel
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Don Armstrong 2007-05-19, 1:20 am |
| On Fri, 18 May 2007, Daniel Burrows wrote:
> I would very much be in favor of adding new, optional fields that
> describe the dependencies of the package. These can be integrated
> into the package management interface at appropriate points, without
> cluttering the description itself.
While I think it would be better to use README.Debian, since you're
going to end up writing one implementation, do whatever you decide is
best.
> Stuffing information into README.Debian doesn't help, since (a) you
> can't read it until you've installed the package, and
Adapting the p.d.o changelog script to do this would allow it to be
seen before the package is installed, so that's not exactly
insurmountable.
> (b) NLP parsing isn't good enough to find the text you need and
> extract it automatically :-).
It's not like it would be difficult to decide on a standard to allow
the segment of text in README.Debian that described the optional
dependencies (or other information that a packagea maintainer thought
people may be interested in knowing as they're deciding what else to
install besides the package.)
In any event, I think I've made my opinion clear enough, so I'll stop
here.
Don Armstrong
--
She was alot like starbucks.
IE, generic and expensive.
-- hugh macleod http://www.gapingvoid.com/batch3.htm
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2007-05-19, 1:20 am |
| Don Armstrong <don@debian.org> writes:
> It's not like it would be difficult to decide on a standard to allow the
> segment of text in README.Debian that described the optional
> dependencies (or other information that a packagea maintainer thought
> people may be interested in knowing as they're deciding what else to
> install besides the package.)
Bleh. This is how we got the Homepage hack in the package descriptions.
Please don't add structure to unstructured data retroactively; it makes
parsing a mess. We already have a clean, structured file in which to
store this sort of information, or we can introduce a new structured file.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-05-19, 1:20 am |
| On Fri, 18 May 2007 08:39:00 +0200, Hendrik Sattler
<debian@hendrik-sattler.de> said:
> 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?".
The dependency of ucf on debconf-utils is a strong, but not
absolute, dependency. In the authors opinion, debconf-utils should be
isntalled with ucf in all but unusual installations.
> I would say no based on the description of debconf-utils just because
> I have not the faintest idea what ucf does with those.
While you are of course entitled to do as you please on your
machine, you are going against the opinion of the maintainer of ucf;
and the utility of the package may be degraded in some circumstances.
> 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).
If you do not wish to educate yourself on the details, perhaps
you should be heeding the directions given to you by the maintainer?
manoj
--
"I say we take off; nuke the site from orbit. It's the only way to be
sure." Corporal Hicks, in "Aliens"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-05-19, 1:20 am |
| On Fri, 18 May 2007 19:43:31 -0400, Felipe Sateler <fsateler@gmail.com> said:
> Don Armstrong wrote:
[vbcol=seagreen]
> But then you could just say: "Useful in case template databases get
> corrupted". There is no need to go and explain details. Just a general
> idea is useful enough. If I were to read that, then I'd say: "Well, I
> guess database corruption means something bad, and I want to recover
> from that whenever possible. Lets install debconf-utils." I don't need
> to know which specific script is being used, what templates are, why
> there is a database of them, and how that database may get
> corrupted. I just know that debconf-utils would be useful in case of
> malfunction. Since malfunction costs more than bandwidth and disk
> space, I'll install it.
Without going into arcane details, you have been told that, in
the maintainers opinion, you should be installing debconf-utils when
you install ucf, unless yours is an unusual installation, and you know
what you are doing.
manoj
--
Take me drunk, I'm home again!
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Greg Folkert 2007-05-19, 1:20 am |
| On Sat, 2007-05-19 at 00:16 -0500, Manoj Srivastava wrote:
> On Fri, 18 May 2007 19:43:31 -0400, Felipe Sateler <fsateler@gmail.com> said:
>
>
> Without going into arcane details, you have been told that, in
> the maintainers opinion, you should be installing debconf-utils when
> you install ucf, unless yours is an unusual installation, and you know
> what you are doing.
Dear Felipe,
You are getting this advice strait from the proverbial "Horses Mouth",
as Manoj is the listed maintainer of the package "ucf", I'd have to
guess his advice is a golden opportunity to get free, the most expensive
advice you'll ever receive.
Just trust him, he truly isn't *evil*.
--
greg, greg@gregfolkert.net
PGP key: 1024D/B524687C 2003-08-05
Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C
Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0
| |
| Kevin Mark 2007-05-19, 1:20 am |
| On Fri, May 18, 2007 at 02:04:15PM -0400, Joey Hess wrote:
> Kevin Mark wrote:
<my desktop user reasoning>>
> 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.
So here is what I take-away from your post:
From the desktop user perspective, they will not know much about what to
select and thus will install the 'desktop' task. They will also not
change the default behavior of aptitude which install 'recommends'. This
[at least according tothe definition] will install usefull things that
most average users of said package will need. Thus they will run the
various pieces of software and should 'just have' most of the expected
functionality available. So, knowing what each 'recommends' adds in
functionality is not needed. And, at the point extra functionality is
needed, the user will have to investigate the available resources,
post-initial-install, like READMEs, man pages, etc. to determine what
should be installed.
While that seems reasonable, I think adding the comment would be great
so that folks could be explicitly told why a 'recommends' is being added,
knowing full-well that its not a replaccement for reading more lengthy
and through documentation because the maintainer knows when they add a
'recommends', it adds something specific and I think that thought should
be conveyed to the future users of the package. And I guess to shorten
the comment, the language for the comment should include domain-specific
terminology and jargon.
You also advocate at the same time for adding a syntax for comments to
various (packaging?) fields, which is, as you say, generally userful. No
argument here.So at some point in the future there will be
infrastructure for said 'recommends' comments. If that does come to
pass, then the functionality can be added to aptitude to read and
display said comments. Hmm. Same result from a different perspetive.
Now as for the need for re-classification of 'recommends' to say
'suggests' to trim (mega|giga)bytes from the basic install sounds like a neat
idea and a way to help with that is to have the maintainer have a simple
file that explains the association between the package and its
recommends(kind of like the proposed comments) so that it can be peer
reviewed if someone questions its usefulness in a regular install with
aptitude.
debian.recommends.txt for mutt
-----------------------------------------------------------
mutt-print: adds a way to print mail using tex formatting
gnupg: used to sign and/or encrypt incomming/outgoing mail
-----------------------------------------------------------
-K
--
| .''`. == 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 _______|
| |
| Hendrik Sattler 2007-05-19, 1:20 pm |
| | |
| Chris Bannister 2007-05-19, 1:20 pm |
| On Sat, May 19, 2007 at 02:08:16AM -0400, Kevin Mark wrote:
> Now as for the need for re-classification of 'recommends' to say
> 'suggests' to trim (mega|giga)bytes from the basic install sounds like a neat
> idea and a way to help with that is to have the maintainer have a simple
> file that explains the association between the package and its
> recommends(kind of like the proposed comments) so that it can be peer
> reviewed if someone questions its usefulness in a regular install with
> aptitude.
>
> debian.recommends.txt for mutt
> -----------------------------------------------------------
> mutt-print: adds a way to print mail using tex formatting
> gnupg: used to sign and/or encrypt incomming/outgoing mail
> -----------------------------------------------------------
Yeah but mutt-print is neither mentioned as a recommends nor a suggests!
--
Chris.
======
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Kevin Mark 2007-05-19, 1:20 pm |
| On Sun, May 20, 2007 at 01:01:18AM +1200, Chris Bannister wrote:
> On Sat, May 19, 2007 at 02:08:16AM -0400, Kevin Mark wrote:
>
> Yeah but mutt-print is neither mentioned as a recommends nor a suggests!
>
it was a made-up example, so next time I'll use the trusty foo and bar
application ;-)
--
| .''`. == 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 _______|
| |
| Manoj Srivastava 2007-05-19, 1:20 pm |
| On Sat, 19 May 2007 13:17:45 +0200, Hendrik Sattler <debian@hendrik-sattler.de> said:
> Am Samstag 19 Mai 2007 07:14 schrieb Manoj Srivastava:
[vbcol=seagreen]
> Perhaps. But first, but not all packages are actually strict about
> that
That would be a bug, then. If you can identify such packages,
could you please file bug reports?
> and I do not want to bloat my installation
Well, for non-buggy packages, what you have is an issue of
trusting the maintainers judgement. In that case, you also have to
trust that the maintainer comes up with a correct, and properly
formulated explanation in under one line; which correctly emphasizes
the importance of the dependency relationship.
Since you don't trust the maintainers judgement in the first
place, I think the lack of space is likely to lead to a situation that
you'll make an equal number of incrorrect decisions dues to lack of
information, incorrectly interpreted information, and other
misunderstanding.
Now, adding such information to the README might not suffer from
the space limitations, but the trust issues still remain.
> and second, if it is really that important (read: essential part of
> functionality) is would be a Depends.
As the policy states; it is a strong, but not absolute
dependency. The core functionality might work. But ease-of-use, and
the optional frills that might make it truly useful might not -- ot the
package may fail in some non-mainstream circumstances (which is the
case with ucf).
> Does it really happen that often that this Recommends is needed. Or is
> it just to be on the safe side?
Unless you are a $Deity, or have conducted an extensive
analysis, this is a matter of judgement. By putting things as
recommends, the maintainer is saying, yes, it is a good thing to
install these packages together.
If you think the maintainers judgement is off, and have some
proof, file a bug to reduce the depndency.
> Anyway, it was just an example out of many. For non-core packages,
> Recommends often add functionality that I'll never use but the package
> maintainer uses them daily. Why should I install it then?
You don't have to. But you are saying you do not trust the
maintainers judgement, so asking in 80 characters or so why things are
needed is not likely to help. You'll be petter off just running
aptitude --withouit-recommends, and adding things you feel, in your
judgement, are truly needed.
manoj
--
Usage: fortune -P [-f] -a [xsz] Q: file [rKe9] -v6[+] file1 ...
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-05-19, 1:20 pm |
| On Fri, 18 May 2007 21:44:43 -0700, Russ Allbery <rra@debian.org> said:
> Don Armstrong <don@debian.org> writes:
[vbcol=seagreen]
> Bleh. This is how we got the Homepage hack in the package
> descriptions. Please don't add structure to unstructured data
> retroactively; it makes parsing a mess. We already have a clean,
> structured file in which to store this sort of information, or we can
> introduce a new structured file.
A field in the control file is unlikely to have enough space to
truly state the reasons (remember, the maintainer has alsready stated
that in their judgement the packages belong together for all but the
most unusual installations). Adding a special file with expanded
explanations or essays might work.
manoj
--
Good salesmen and good repairmen will never go hungry. R.E. Schenk
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| cobaco (aka Bart Cornelis) 2007-05-19, 1:20 pm |
| On Saturday 19 May 2007, Manoj Srivastava wrote:
> Well, for non-buggy packages, what you have is an issue of
> trusting the maintainers judgement. In that case, you also have to
> trust that the maintainer comes up with a correct, and properly
> formulated explanation in under one line; which correctly emphasizes
> the importance of the dependency relationship.
> Unless you are a $Deity, or have conducted an extensive
> analysis, this is a matter of judgement. By putting things as
> recommends, the maintainer is saying, yes, it is a good thing to
> install these packages together.
> If you think the maintainers judgement is off, and have some
> proof, file a bug to reduce the depndency.
>
>
> You don't have to. But you are saying you do not trust the
> maintainers judgement, so asking in 80 characters or so why things are
> needed is not likely to help.
I have to strongly disagree with the opinion that this shows distrust in the
maintainers judgement for 2 reasons IMO:
1) wanting more information is (in itself) in no way a sign of distrust
2) maintainers make decisions that are supposed to be reasonable to
a regular user. However not everyone is a regular user, and in situations
where one isn't, you might want to reexamine the decisions made.
Not because of trust issues, but simply because some of the underlying
assumptions might not apply
Informing people is a Good Thing. So what if only a small percentage of our
users will ever use the extra information, I don't see how the existence of
that information would cause any problems
-> so as long as somebody is willing to do the work for providing it I don't
see the problem with supporting a standard system for putting the
information in the user's hands.
--
Cheers, cobaco (aka Bart Cornelis)
| |
| Felipe Sateler 2007-05-19, 7:17 pm |
| Manoj Srivastava wrote:
> Without going into arcane details, you have been told that, in
> the maintainers opinion, you should be installing debconf-utils when
> you install ucf, unless yours is an unusual installation, and you know
> what you are doing.
True. However, lets not forget that this is supposed to apply to suggests as
well, for which this information would be more useful.
Don Armstrong wrote:
> You could just as easily assume that the package
> maintainer knows what they're talking about when they mark a package
> as Recommends: and assume that it should be actually installed in the
> default case.
That is the assumption that isn't accurate, in my experience. The maintainer
often will have a different opinion on what is the common use of a program.
While most of the time you can guess why a package has been recommended,
sometimes the relation isn't obvious, and a hint would be helpful.
OTOH, I'm not going to implement any of this, so I'll just shut up, and
apologise for the noise.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Erik Steffl 2007-05-19, 7:17 pm |
| Manoj Srivastava wrote:
> On Sat, 19 May 2007 13:17:45 +0200, Hendrik Sattler <debian@hendrik-sattler.de> said:
>
>
>
> That would be a bug, then. If you can identify such packages,
> could you please file bug reports?
>
>
> Well, for non-buggy packages, what you have is an issue of
> trusting the maintainers judgement. In that case, you also have to
> trust that the maintainer comes up with a correct, and properly
> formulated explanation in under one line; which correctly emphasizes
> the importance of the dependency relationship.
>
> Since you don't trust the maintainers judgement in the first
> place, I think the lack of space is likely to lead to a situation that
> you'll make an equal number of incrorrect decisions dues to lack of
> information, incorrectly interpreted information, and other
> misunderstanding.
maintainer did not decide that dependency is in order but chose
recommend/suggest instead - of course I want to know why so that I can
figure out whether I am in the minority that does not want the package
installed - it might be useless or even have unwanted effects on my
usage of the package (or on my system).
the idea that if you are in the minority you already know it is
broken, you cannot know that until you know, at least aproximately, what
does the recommending package use recommended package for.
the issue of trusting the maintainer is irrelevant, I trust the
maintainer but I want enough information to be able to collapse the wave
function of probably (recommended packages) and possibly (suggestions).
....
> Unless you are a $Deity, or have conducted an extensive
> analysis, this is a matter of judgement. By putting things as
> recommends, the maintainer is saying, yes, it is a good thing to
> install these packages together.
exactly. In other words it means that the maintainer is saying that
in some cases you might not want the recommended package installed.
you keep describing this from maintainer's perspective, imagine
yourself at hands of other expert that you trust - auto-mechanic,
doctor, teacher etc. You never asked question and always did what they
recommneded without question, even in cases you KNEW they do not know
details of your specific situation?
erik
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Charles Plessy 2007-05-20, 1:21 am |
| Le Sat, May 19, 2007 at 09:52:44AM -0500, Manoj Srivastava a écrit :
>
> A field in the control file is unlikely to have enough space to
> truly state the reasons (remember, the maintainer has alsready stated
> that in their judgement the packages belong together for all but the
> most unusual installations). Adding a special file with expanded
> explanations or essays might work.
Hi all,
I am quite convinced that recommended packages do not need to be
justified, but I think that the need for such a justification in the
case of suggested packages will go growing. Soon or later, the apt
frontends will be able to use Debtags smartly, and suggest packages by
themselves. Then what will remain in the Suggests: field of the control
file will indeed be what is difficult to guess and needs to be
explained.
By the way, Manoj, I think that I did not understand why you say that
there is not enough space in the control file while it is able to host
the long description of packages? We could have something like:
Suggests: foo, bar, baz
Justify-foo: To play while the program works for you.
Justify-bar: Here a longer discussions which
takes advantages of the format
of the control file
Justify-baz: You can use baz instead of bar.
Have a nice day,
--
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-05-20, 1:21 am |
| On Sun, 20 May 2007 10:23:51 +0900, Charles Plessy <charles-debian-nospam@plessy.org> said:
> I am quite convinced that recommended packages do not need to be
> justified, but I think that the need for such a justification in the
> case of suggested packages will go growing. Soon or later, the apt
> frontends will be able to use Debtags smartly, and suggest packages by
> themselves. Then what will remain in the Suggests: field of the
> control file will indeed be what is difficult to guess and needs to be
> explained.
> By the way, Manoj, I think that I did not understand why you say that
> there is not enough space in the control file while it is able to host
> the long description of packages? We could have something like:
> Suggests: foo, bar, baz
> Justify-foo: To play while the program works for you. Justify-bar:
> Here a longer discussions which
> takes advantages of the format of the control file
> Justify-baz: You can use baz instead of bar.
So now you have a variably named field in the control file --
which is legal, but does require a bit more intelligence for parsing
programmatically.
manoj
--
"There is no pleasure in having nothing to do; the fun is in having lots
to do and not doing it." -Mary Wilson Little
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sánchez 2007-05-20, 1:21 am |
| On Sat, May 19, 2007 at 09:43:20PM -0500, Manoj Srivastava wrote:
> On Sun, 20 May 2007 10:23:51 +0900, Charles Plessy <charles-debian-nospam@plessy.org> said:
>
>
>
> So now you have a variably named field in the control file --
> which is legal, but does require a bit more intelligence for parsing
> programmatically.
>
Something like /^Justify-\([^:]+\):/ should do it, right? Then $1
becomes the package name.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
| |
| Daniel Burrows 2007-05-20, 7:21 pm |
| On Sat, May 19, 2007 at 09:52:44AM -0500, Manoj Srivastava <srivasta@debian.org> was heard to say:
> A field in the control file is unlikely to have enough space to
> truly state the reasons (remember, the maintainer has alsready stated
> that in their judgement the packages belong together for all but the
> most unusual installations). Adding a special file with expanded
> explanations or essays might work.
The goal is not to produce an iron-clad defense of your judgement,
it's to allow the user to make a more informed judgement than they
could otherwise make.
I've drawn some packages fully at random from the package list to see
whether there's any reason to believe that we couldn't construct a helpful
explanation of their suggestions. It's interesting to note that
somewhere around 3/4 of the packages I checked didn't have any
suggestions or recommendations at all, so even if we tried to document
all suggestions fully, most packages would be unaffected.
========================================
===============================
pop-before-smtp Suggests: imap-server | pop3-server
Suggests-Reason: imap-server | pop3-server: because pop-before-smtp needs access to the log file of your POP3 or IMAP server.
pop-before-smtp scans the logs of your POP3 or IMAP server in order to
detect user logins. If the server is running on another computer, you
must provide access to its log files on this computer (for instance, by
enabling remote syslog access).
========================================
===============================
========================================
===============================
kdeaccessibility-doc-html Suggests: kdebase
Suggests-Reason: kdebase: to run the software this package documents.
========================================
===============================
========================================
===============================
kdeartwork-misc Suggests: kworldclock
Suggests-Reason: kworldclock: to make use of the kworldclock themes included in this package.
========================================
===============================
========================================
===============================
ttf-bengali-fonts Suggests: x-ttcidfont-conf
Suggests-Reason: x-ttcidfont-conf: to automatically register these fonts with the X window system.
========================================
===============================
========================================
===============================
pida Suggests: bicyclerepair
Suggests-Reason: bicyclerepair: because bicycle-repair is a useful Python tool that I like.
========================================
===============================
(I installed both pida and bicycle-repair, and as far as I can tell,
this is the only relationship between them. bicycle-repair has IDE
plugins...but there doesn't seem to be one for pida)
Daniel
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Brian May 2007-05-21, 1:22 am |
| >>>>> "Don" == Don Armstrong <don@debian.org> writes:
[vbcol=seagreen]
Don> If you're not going to explain what it actually does, why
Don> bother writing it at all? You could just as easily assume
Don> that the package maintainer knows what they're talking about
Don> when they mark a package as Recommends: and assume that it
Don> should be actually installed in the default case.
Don> The information above isn't enough to make a rational
Don> decision as to whether you really need debconf-utils when
Don> you've got ucf installed or not.
Another user might look at the same package, with the description and
think "this computer only has a restricted amount of disk space and I
really don't care if the database does get corrupted - I don't expect
this system to be around much longer anyway - so I will ignore the
suggestion and won't install the package."
With no description it might be more along the lines of "I don't know
why this package is suggested maybe I will have to install it anyway
just in case... Lets hope I have enough disk space..."
(sure, it is unlikely you would run out of disk space installing the
mentioned package, but for the general case, it is very possible.)
--
Brian May <bam@snoopy.debian.net>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Brian May 2007-05-21, 1:22 am |
| >>>>> "Hendrik" == Hendrik Sattler <debian@hendrik-sattler.de> writes:
Hendrik> Perhaps. But first, but not all packages are actually
Hendrik> strict about that and I do not want to bloat my
Hendrik> installation and second, if it is really that important
Hendrik> (read: essential part of functionality) is would be a
Hendrik> Depends. Does it really happen that often that this
Hendrik> Recommends is needed. Or is it just to be on the safe
Hendrik> side? Anyway, it was just an example out of many. For
Hendrik> non-core packages, Recommends often add functionality
Hendrik> that I'll never use but the package maintainer uses them
Hendrik> daily. Why should I install it then?
In the past I have seen (broken) packages that recommend "apache"[1].
Huh? Does this mean the package is incompatible with apache2?
In fact, I suspect at least some these packages may work fine with
other httpd daemons that the maintainer didn't know about at the time.
Just because the maintainer recommends that I should have "apache"
installed doesn't mean it will loose functionality if "apache" is not
installed - unless it really is some weird package that depends on
this obsolete version of apache.
A description of "to support the HTTP protocol" would imply that the
version is not important.
Notes:
[1] as far as I can tell most packages now depend on httpd as an
alternative, so perhaps this specific example is no longer an
issue. However the concept still stands.
I did notice one package (education-main-server) recommends "apache2 |
apache" but I am not going to try and work out if apache is really
required or not.
--
Brian May <bam@snoopy.debian.net>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-05-21, 1:22 am |
| On Mon, 21 May 2007 13:38:58 +1000, Brian May <bam@snoopy.debian.net> said:
Hendrik> Perhaps. But first, but not all packages are actually strict
Hendrik> about that and I do not want to bloat my installation and
Hendrik> second, if it is really that important (read: essential part of
Hendrik> functionality) is would be a Depends. Does it really happen
Hendrik> that often that this Recommends is needed. Or is it just to be
Hendrik> on the safe side? Anyway, it was just an example out of
Hendrik> many. For non-core packages, Recommends often add functionality
Hendrik> that I'll never use but the package maintainer uses them
Hendrik> daily. Why should I install it then?
[vbcol=seagreen]
> In the past I have seen (broken) packages that recommend "apache"[1].
Did you file a bug?
> Huh? Does this mean the package is incompatible with apache2?
Did you ask in the bug report you filed?
> Just because the maintainer recommends that I should have "apache"
> installed doesn't mean it will loose functionality if "apache" is not
> installed - unless it really is some weird package that depends on
> this obsolete version of apache.
If you don't trust the maintainers recommends, why do you
think you'll trust a one sentence description?
> A description of "to support the HTTP protocol" would imply that the
> version is not important.
Recommends: apache. Reson: needs apache to provide documentation.
I doubt you'll find things very much improved.
> Another user might look at the same package, with the description and
> think "this computer only has a restricted amount of disk space and I
> really don't care if the database does get corrupted - I don't expect
> this system to be around much longer anyway - so I will ignore the
> suggestion and won't install the package."
> With no description it might be more along the lines of "I don't know
> why this package is suggested maybe I will have to install it anyway
> just in case... Lets hope I have enough disk space..."
Recommends: apache. Reson: needs apache to provide added
functionality.
If you are that short of disk space, _do_ run with apt0tude
--without-recommends.
manoj
--
Objects in your terminal are close than they appear.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ian Jackson 2007-05-29, 1:23 pm |
| Don Armstrong writes ("Re: Reasons for recommends and suggests"):
> On Fri, 18 May 2007, Hendrik Sattler wrote:
>
> 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.
I think the information about Suggests and Recommends should go in the
Description: in unstructured text for now. I have been doing that for
my packages forever. You put a separate paragraph in the Description
which explains what facility the Suggested and Recommended packages
provide.
NB that often the answer is `obvious' so I wouldn't say that there
should be a policy for this information always to be present. The
maintainer should decide, after listening to the users (who are after
all the people who know what information they're lacking, whereas the
maintainer typically already knows).
It may turn out to be useful later to have some machine-parseable
structured form for this information, but that still has to be designed.
Putting it into the Recommends and Suggests fields directly doesn't
seem like a good idea. The format of those fields is too constrained
and it would make providing translations very difficult.
I also disagree with the suggestion that the information should be in
README.Debian. It needs to be available when deciding whether to
install a package - so it should be in the .deb control file where it
will end up in Packages.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|