Re: [gentoo-dev] Improved ebuild information

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Ok really first off, I am not a gentoo developer, just to let you know :)

First off, everything here is basically taken out of context from
gentoo-portage-dev, so the only sane responses ( to this mail, not the
other one, which was different ) are going to be from people who read both.
>
>>> In my opinion, the easiest way would be a wiki.
>>
>>
>>
>> Indeed. But why do you need to modify all the ebuilds?
>
>
> do i have to? of course it is not necessary to modify 10k ebuilds in a
> week. The line could be added on the next regular update. And as said
> below, it could also be generated automatically by the tool that reads
> the packages metadata.
>

Regardless of where this data is going, SOME{ONE,THING} has to compile
it all.  You spoke on the other ML of HOW-TO links and all manner of
info.  That info is great.  The problem is convincing ebuild developers
to compile the data in the first place, and keep it accurate.  That is
why we suggested you try your ideas here.  Writing this stuff into a
tool or patching portage is useless if no one compiles/updates this
information.

> All that has to be done is create a way to print the path to a wiki-page.
> Maybe auto-created by eix. Or maybe a new tool named "einfo" that prints
> the information included in metadata.xml.
>
> greets,
> Caliga

Case 1: Project specific things -> Homepage, guides, HOW-TO's
I like what you are looking for, however I don't think it should be a
Gentoo-specific project.  If one was to make some sort of online
repository of packages and associated helpful guides on using them, that
would be cool.  Even cooler would be if it stood alone from Gentoo ( not
 a gentoo-only project ).  Then every distro could use it, along with
most other UNIXes.

Then you can make a command-line tool or whatnot to query the on-line
database for the information you are looking for.

In any case, I personally don't believe any of this belongs in portage,
metadata.xml or wherever.  Portage's job is to install packages.  I
don't think many people want tons of irrelevant data in the tree, most
people have no problem using a search engine to find it anyway.

Case 2: USE flag specific things.
This is more tricky.  In the current version of portage USE flags are
the only way to enable things on a per-package basis.  This gives us
wonderful things like USE="debug" which is just ass-backwards.  People
use USE flags for things that in most cases aren't meant for USE flags
or go against the global USE flag usage.

You will get cases where USE flag usage is abnormal.  In that case I'd
file bugs against respective packages ( aka, when a global USE flag is
used in a way that doesn't jive with that USE flag's global usage. ).
If you want to query what flags do, there are utilities for that ( ufed,
pyfed? ).  If you want more descriptive usage of USE flags, bug the
ebuild developers to add more text to the appropriate file, or read the
ebuild.

Case 3: Update Paths
For major packages Gentoo generally does a decent job providing upgrade
documentation.  Either the lead dev for that herd/project will write it
up in their devspace, or put it somewhere.  It's often printed at
install time as well, and there are tools to catch all those handy
messages :)
However there are many smaller packages that don't get this kind of
support and you are sometimes left fending for yourself a bit as to
figuring stuff out, or the solution to your problem is printed at
install time ( by install time, I mean post_inst() in portage terms ).
I've already had that argument on this list though, and it basically
came down to better gentoo commit messages and the fact that the gentoo
developers are not responsible for keeping me informed about my packages
and whether this upgrade breaks them.  And honestly, I understand that.

Part of the coolness/problem with gentoo is that you are basically left
as your own system administration.  This isn't redhat where you are
handheld through everything.  Many people get along that way on gentoo,
stuff breaks, they reinstall, end of story.  If you are upgrading
package foo and you don't know if it's important or not, or if it will
break your system you may want to go and check it out.  What does foo
do, what depends on foo ( equery and gentoolkit )?  Check
bugs.gentoo.org or foo's bugzilla for open bugs and check foo's
Changelog ( the package changelog mind, not the gentoo changelog ).

Good Luck,

Alec Warner ( antarus )
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQz9HamzglR5RwbyYAQLiLw//epYhdGOnSM2KUC8hFRkVin4f+KDPNxf1
QvbbfX3gaEfryY2PymcjoOmfWYzySPD6SJhrETnscVMU3lSS26xFSuKdSP+T66rK
a9zvO+JeVn+GDm+dyVLjZxtJTLcv23bCzwrS4EcNVpT33iV0OkYkKHIKPqcGh02O
GxMmKi3SD5wz6mJYzm9tDAdCxsb7g3TaWJlpUm99wvkcf+JlZLSomz3odxCB7mh8
bQqcpyCyrpdpD/FnrE6GQ68NTg2Axfsck85SwcGdJAgwR7yi9pr3ZSKUZKe19AoY
Fz/xQIKIXAlUzRHdAIP3k/nTWawXU0+pucsWJy6S84qsJ+1GIY2EwWU8wpd51llc
k6vPTb+k7X9IGo2uNQvyqIIsHruw9Qi0ZiswF8r8d4gZarBBzaTixoK9ThGU/uvg
zLdfYS+1VeIB/3F1MZ3DW4heVGPriZ9H+xxjG9seD5CbqsT2gIVGeyYVwkzx+8LT
N6Pz6PiUb1OxZoXyOyLCneE/JsEN3UTFBgpbfqUb061N+0eTPyI+46juuF+N50cE
g1fcDnvlGVOYvCGRbaursK2HNK/TqBcXoz0xMB10eJkuh+TX5triK6Xhgaxn51gc
x1m2GzZ58K2th0xlsCw/0mk/kILvHYN9Sb8hk/cHEoHg2QnxrdyoPr9ecoG+StHM
FgqIJvNeNxE=
=9WY7
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list