public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Daniel Stiefelmaier <mail@stiefelweb.de>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] Improved user information and communication
Date: Sat, 01 Oct 2005 23:57:01 +0200	[thread overview]
Message-ID: <433F062D.2010805@stiefelweb.de> (raw)
In-Reply-To: <433EEC96.9070102@gentoo.org>


>> 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?

err.. i think you got me wrong... i do not expect emerge to have a 
built-in list of use flags.
The description should be in the .ebuilds or metadata.xml
But i hope you do agree, that eix or emerge are the appropriate tools to 
dig such information.
(maybe eix more than emerge)
Just like "emerge -vv" will print information about the ebuild 
maintainers in future release, if i got that right.

>> 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?

- ease of use
- elegance
- not need to know about every portage file (especially if new to gentoo)
- time efficiency (for dozens of flags)
- non-global flags

eix also provides only information that you could grep in a more or less 
elegant way.
or using google...


>> 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.

most programs, even those for gurus, print information about their 
option or AT LEAST how to GET information. still, these programs are 
"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.

even emerge is "just for the user's convenience"
even distributions are "just for the user's convenience", who needs them?
i never heard someone argueing that a feature is needless because it is 
convenient.
features are there to be convenient.

> 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.

what should i say? don't you have bookmarks of good sites? do you always 
google for them?
of course you will get what you want in many cases but not always.

another unix principle is that everybody can do everything the way he 
likes. in this case, i prefer to have a "readers choice" instead of 
googling and digging the perls.

also, i agree that emerge may not be the right tool for that. may be 
"eix" or a new one.
what this is about, is including additional information (only one link 
that will not hurt you) in the ebuilds or metadata.xml

> Do you think we're all sadists?

No, but hard to believe that you are not ignorant against people
- that like to have features you personally find useless
- that may be not using linux since 1992 and need more good 
documentation to install and maintain their system
- that (therefore) do not know the linux/gentoo/portage file structure 
by heart

> Sorry, but such statements don't help your argumentation.

Did you think the statements in Jasons first reply were all helping the 
discussion?

>> 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.

This sounds like they are needless.

> 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 did not yet dive into portage, but why is it such a big effort? For 
the ebuilds themselves it is adding one more line on the next regular 
update. (This would be for the wiki. If the help on the useflags would 
be included in the ebuild and not in the wiki, yes, then it would be a 
bit more effort. But i guess the maintainers know their flags and could 
add some lines that describe them quickly)

>> 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.

IMHO it is a helpshift

Caliga
-- 
gentoo-portage-dev@gentoo.org mailing list



  reply	other threads:[~2005-10-01 21:51 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
2005-10-01 21:57           ` Daniel Stiefelmaier [this message]
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=433F062D.2010805@stiefelweb.de \
    --to=mail@stiefelweb.de \
    --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