public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Simon Stelling <blubb@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] Improved user information and communication
Date: Sat, 01 Oct 2005 22:07:50 +0200	[thread overview]
Message-ID: <433EEC96.9070102@gentoo.org> (raw)
In-Reply-To: <433EE651.1060403@stiefelweb.de>

Hi,

Daniel Stiefelmaier wrote:
>> Take the USE flag "perl", for example. It has the description "Adds 
>> support/bindings for the Perl language." but for mysql setting it 
>> enables the installation of some support scripts that just happen to 
>> be written in perl.

Since perl is a global use flag, this is inappropriate use. You might want to 
file a bug :)

> man emerge provides information on possible options, why should there 
> not be a way to get information on an ebuilds option???

because emerge is the tool, not the object. You wouldn't expect the openoffice 
documentation to cover examples for different kinds of letters, would you?

> The useflag "xprint" sounds like printing support, but doesn't tell if 
> you need it if you use cups or the kde-printing system or... whatever.

~ $ grep xprint /usr/portage/profiles/use.desc
xprint - Support for xprint, http://www.mozilla.org/projects/xprint/

what do you need more?

> - There are many Gentoo-related HOWTOs, not linked on a projects homepage

You can easily find those through searching google

> - Some ebuilds give homepages like "gnome.org" just for some little 
> gnome app that is not linked on gnome.org

Same here, googling usually helps

> - There are not only howtos but other useful related pages

Same here.

> Why do you think just because YOU don't need it, noone will?

This is not a personal debate. The most important reason I see against this idea 
is that portage is a package manager, not a documentation center.

Why should the ebuild contain links to documentation? To be honest, not even the 
HOMEPAGE info is needed, it's just for the user's convenience. I tend to refer 
to the UNIX principle: The right tool for the right job. For your problem, 
google (or any other search engine of course) is the right tool.

> No, don't give information to users! Don't have a defined way to get 
> information to a package! It's evil!

Do you think we're all sadists? Sorry, but such statements don't help your 
argumentation.

>>> BTW, if "This is out of the domain of a package in any package
>>> management system", then why do some packages print additional
>>> information after emerging, like what files should be updated manually?

For the user's convenience of course. Introducing documentation links in ebuilds 
  however is a massive effort, and I don't think that effort is worth it. I'd 
rather fix a broken package than googling for documentation.

I'm sure every user is able to search for HOWTOs, but not every user is able to 
fix a broken package himself.

> That question was rhetorical. Of course it's because portage can't 
> handle everything.
> This is why there should be an easy, defined way to get information.

This defined way is google, IMHO.

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-portage-dev@gentoo.org mailing list



  reply	other threads:[~2005-10-01 20:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-01  5:01 [gentoo-portage-dev] Improved user information and communication Daniel Stiefelmaier
2005-10-01  5:17 ` Jason Stubbs
2005-10-01 16:08   ` Daniel Stiefelmaier
2005-10-01 17:04     ` Jason Stubbs
2005-10-01 19:41       ` Daniel Stiefelmaier
2005-10-01 20:07         ` Simon Stelling [this message]
2005-10-01 21:57           ` Daniel Stiefelmaier
2005-10-01 22:25             ` Brian Harring
2005-10-02  2:54               ` Daniel Stiefelmaier
2005-10-02 11:45                 ` Simon Stelling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=433EEC96.9070102@gentoo.org \
    --to=blubb@gentoo.org \
    --cc=gentoo-portage-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox