Re: [gentoo-portage-dev] New preserve-libs feature
Marius Mauch wrote: So everyone who has valid objections to the _general idea_ of this implementation (preserving old libraries to avoid some runtime linker errors) speak up now. For how long are these libraries preserved? This might have a security impact in cases like the recent openssl-case where you had to upgrade to an incompatible ABI because the version using the old one was vulnerable. Using preserve-libs it would leave the old lib around, making it possible for programs to link against the wrong version and ending up being vulnerable. I realize that the feature is meant to help the transitional phase until all apps are built against the new ABI, but how would you find these vulnerable apps currently? revdep-rebuild wouldn't rebuild them since they are still functional. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] --config-root command-line option
Daniel Barkalow wrote: Allow PORTAGE_CONFIGROOT to be set as a command-line option. It can be annoying to get environment variables to emerge, particularly when you need sudo and you only want the environment variable some of the time. I think it would be better to solve the problem with sudo at its root: /etc/sudoers has the following: # Reset environment by default Defaultsenv_reset Commenting that out reverts this annoying behaviour and fixes all kinds of bugs. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] GLEP 14?
John J Lee wrote: So, is there some work that needs to be done on portage before step 3 happens -- i.e. is now the wrong time to be doing that work? Or is it just lack of somebody to do it? In short: No, yes, yes. What really is needed is sets support in portage. See bug 144480 for that. [1] http://bugs.gentoo.org/show_bug.cgi?id=144480 -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
Zac Medico wrote:
If we implement the repo-level profile, it can have a
bashrc (much like profile.bashrc) that acts as a repo-level ebuild template
(like install-helpers.eclass). Actually, the repo-level profile already
exists
in the form of files such as ${PORTDIR}/profiles/{package.mask,arch.list},
though it doesn't yet have support for a bashrc (ebuild template).
Well, this is a nice idea, but not applicable to this problem. I had a
chat with Brian some days back, and the conclusion was that factoring
out the helper functions is basically an EAPI change. If we handle it
transparently, as in either using PORTAGE_AUTOLOAD_ECLASS or the
repo-level profile, we move parts of the EAPI out into the tree, which
is a bad idea because we are unable to support multiple versions. As the
EAPI needed for the ebuild is unknown when sourcing
install-helpers.eclass, we're actually forced into using that one and
only version, which is quite limiting.
So, the correct way to do it is to define an EAPI=1 that does no longer
include these helper functions and make the eclasses/ebuilds that use it
inherit the eclass manually. However, this will need to run through -dev
and I'm afraid the ebuild devs wouldn't like it at all :-/
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 developer
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
Zac Medico wrote: Well, if the metadata generation step is viewed as being separate from the rest, and the helpers aren't needed during that step, then it's possible to get the EAPI from the ebuild without the helpers being in the environment. Once the EAPI is known, the package manager can use that to determine what else (if anthing) needs to be added to the environment. Then you'd only need a way to tell the package manager which EAPI levels the functions in your install-helpers.eclass (or whatever) apply to. That is a workaround, but it makes a pretty hard link between the package manager and the functions, which is exactly what I am trying to cut through with the patch. Sure, it'd be a workaround, but just keeping them in the portage package until EAPI=1 is reached is one too... So, the correct way to do it is to define an EAPI=1 that does no longer include these helper functions and make the eclasses/ebuilds that use it inherit the eclass manually. However, this will need to run through -dev and I'm afraid the ebuild devs wouldn't like it at all :-/ They won't like it because it's expected that EAPI will provide the necessary information. Why should they have to inherit some special eclass if it's already implied by the EAPI that they've specified? It wouldn't be implied anymore. The install-helpers.eclass would actually be like every other eclass, like eutils fex. Actually, the reason they won't like it for will more likely be that it requires adding another eclass to the inherit line for ~15'000 ebuilds. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
Brian Harring wrote: Make this change, and it means that all overlays that can function as standalone, must bundle the eapi helpers themselves. Not true. I don't have to add eutils.eclass to my overlay to use epatch. Same goes for install-helpers.eclass. Standalone-repos will have that problem, but there is none yet to my knowledge. Sure, the problem persists for future repos, but it's not so much of a deal to copy an eclass once. Also, as it stands today, portage IS connected to gentoo-x86 through exactly these helpers. Upon the needs of the portage tree the functions in portage are changed, and this is simply not correct. This is ignoring the potential fun of an overlay that redefines an eapi locked function. eclasses in overlays that also exist in the tree are fun anyway. If people are messing with eutils, we tell them that it is entirely their responsibility if something breaks. Same goes for install-helpers.eclass. That being said, this problem already exists today: A custom eclass could simply define a function 'dosbin' and ebuild.sh would use that one. While it's a possible cause for breakage, it's not an argument against the move. A) requirement of trying to keep helper functionality exactly in sync per tree, If the helpers were a part of the EAPI those trees would have to verify that the EAPI portage provides matches their needs. Whether you sync against portage or the portage tree is not a big difference. B) fragmentation this implicitly enables isn't good. I agree here. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Moving ebuild-related where they belong
Hi all,
I have thought a bit more about how to better organize the bash-side of
portage and came to the conclusion that modularization of ebuild.sh (as
proposed in the recent thread Refactoring ebuild.sh) can't be the only
and is not the best thing to do.
There is a fair amount of shell scripts and functions in the portage svn
repo that do not really belong there. For example all do*/new* scripts
in the bin/ directory. These are scripts that are not specific to
portage's implementation but the ebuilds that use it. That's why I think
we should move them more towards the ebuilds: Inside the tree.
This has the advantage that paludis/pkgcore don't have to keep their
helper scripts in sync with portages, that they get more visible to
ebuild devs (to some, especially the new ones, they seem like magic
commands that just come out of the middle of nowhere) and most
importantly, that they are where they belong. ;o)
Having them in the tree rather than portage would avoid bugs along the
lines of bug 121317 [1] and bug 136792 [2], or at least pull them off
portage's radar. As those functions are really the ebuild devs' area,
that's only a good thing, IMO.
As they reminded me very much of eclass functions, I converted them into
functions and put together an 'install-helpers.eclass'. Having them as
functions has the advantage of being able to create all of the new*
functions with zero redundancy and only few lines of code and being in
the same line as other helping utilities like the ones provided by
eutils and other eclasses. It has the disadvantage of not being able to
execute them with `find -exec' or `xargs'. However, that is not too much
of a problem in my eyes: I scanned the tree and out of the ~2400 ebuilds
that use find -exec/exec/xargs, none used it in combination with the
scripts I propose to convert to functions.
Having them in an eclass raises the problem of ebuilds having to inherit
said eclass, though. Even if it would be the correct way, I am not all
that keen on adding a 'inherit install-helpers' to ~15'000 ebuilds, so I
solved the problem this way:
--- ebuild.sh 2006-09-03 15:39:22 UTC
+++ ebuild.sh 2006-09-03 15:53:02 UTC
@@ -1350,6 +1350,9 @@
# this can be left out of ebd variants, since they're unaffected.
unset EBUILD_DEATH_HOOKS
+# let the profiles define eclasses to automatically load for every ebuild
+[[ -n ${PORTAGE_ECLASS_AUTOLOAD} ]] inherit ${PORTAGE_ECLASS_AUTOLOAD}
+
source ${EBUILD} || die error sourcing ebuild
if ! hasq depend $EBUILD_PHASE; then
RESTRICT=${PORTAGE_RESTRICT}
Setting PORTAGE_ECLASS_AUTOLOAD enables every repository to define its
own set of standard functions.
Note that I don't really care how the functions/scripts get into the
tree, it only matters to me *that* they are in the tree, so I'm open to
other suggestions. Also, this is probably not the only heap of functions
to move out of portage into the tree, I just didn't want to do more
before I know what way to choose.
Suggestions, comments, alternative approaches, flames, all are welcome.
[1] http://bugs.gentoo.org/show_bug.cgi?id=121317
[2] http://bugs.gentoo.org/show_bug.cgi?id=136792
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 developer
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Original Author: Simon Stelling [EMAIL PROTECTED]
# Purpose: Install helpers to facilitate various actions performed in
# src_install
#
# Note: All of these were moved out of portage as they are only
# ebuild-specifc
ECLASS=install-helpers
#
# into*/*opts section
#
# These functions control where and how files/directories given to do* and
# new* functions are installed.
into() {
if [ $1 == / ]; then
export DESTTREE=
else
export DESTTREE=$1
if [ ! -d ${D}${DESTTREE} ]; then
install -d ${D}${DESTTREE}
fi
fi
}
insinto() {
if [ $1 == / ]; then
export INSDESTTREE=
else
export INSDESTTREE=$1
if [ ! -d ${D}${INSDESTTREE} ]; then
install -d ${D}${INSDESTTREE}
fi
fi
}
exeinto() {
if [ $1 == / ]; then
export EXEDESTTREE=
else
export EXEDESTTREE=$1
if [ ! -d ${D}${EXEDESTTREE} ]; then
install -d ${D}${EXEDESTTREE}
fi
fi
}
docinto() {
if [ $1 == / ]; then
export DOCDESTTREE=
else
export DOCDESTTREE=$1
if [ ! -d ${D}usr/share/doc/${PF}/${DOCDESTTREE} ]; then
install -d ${D}usr/share/doc/${PF}/${DOCDESTTREE}
fi
fi
}
insopts() {
export INSOPTIONS=$@
# `install` should never be called with '-s' ...
hasq -s ${INSOPTIONS} die Never call insopts() with -s
}
diropts
Re: [gentoo-portage-dev] Refactoring ebuild.sh
Brian Harring wrote:
categorization is a bit whonky in a few spots-
I won't fight that. It was pretty hard to categorize functions that I've
never really noticed before ;)
Debugging:
register_die_hook()
ebuild specific func, while debugging, it's not ebuild.sh debugging.
diefunc()
dump_trace()
these are general utility, not debugging.
Where would you stick them? 'die' to 'ebuild helpers' and 'dump_trace'
to 'internals'?
Action functions:
dyn_setup()
dyn_unpack()
dyn_clean()
dyn_compile()
dyn_test()
dyn_install()
dyn_preinst()
dyn_help()
Abort handlers:
abort_handler()
abort_compile()
abort_unpack()
abort_test()
abort_install()
killparent()
internal is a better label.
Well, that stuff under 'Abort handlers:' which I accidentally indented
was intended to go in an own file. However, seeing the list this way, it
might be better to stick them in the same one, which the label internal.
Could also put the 'Internal helpers' there as they are really short anyway.
has is missing also...
Well, has* is already in isolated-functions.sh. I've thought about
killing that and moving the functions to the appropriate sections, but I
was not sure whether isolated-functions.sh was sourced from different
places too so that I simply put it off for the moment. If it's not
sourced otherwise, I'd certainly move the functions there too.
If you're going to try breaking the beast up, suggest you go the step
further and break up what must be supplied from the ebuild.sh
implementation, and what is bound to the ebuild's environment.
Internal eclass functions:
newdepend()
newrdepend()
newpdepend()
do_newdepend()
These aren't eclass functions- usable without involving eclasses.
inherit ought to be in internal eclass functions also (yes it's user
visible, but it's also ebuild.sh implementation specific).
Where to put them, then?
I moved them into own files within a subdir in bin/, called modules, and
source these files at the right time, so that nothing changes
functionality wise. The global scope code I left untouched, except for a
bunch of exports that set sane defaults for the do*/new* helpers.
This cuts down ebuild.sh to 403 lines, which makes it far more readable,
IMO.
Except there are now magic vars hidden away in submodules. If trying
to seperate it into seperate blocks, document 'em.
Uhm, how would that documentation part work? What exactly do you want
documented? (What do it and 'em refer to?)
About the magic vars.. I wasn't sure either whether putting the defaults
into the modules was a good idea. I thought it would be good because
they are not used anywhere else (didn't check), but I can just as well
stick them back into ebuild.sh.
I also set all the functions that aren't meant to be overridden by saved
env, profile bashrc, portage bashrc or ebuilds/eclasses readonly.
Don't think much thought was put into this tbh- use* and has* (all but
useq and hasq basically) are bound to the ebuild environment.
This is actually true.
Why? Because they got mangled transitioning from 2.0.50 2.0.51, for
the ebuild to function properly it needs to use the original func from
the environment, not what the ebuild.sh implementation tries to force.
Identified all of them that are affected by this?
Well, as it stands now, all variables except the sandbox related ones
are defined after env bashrc are sourced and before the ebuild is
sourced. That means that the env can't override them, which means that
they are considered implementation specific in the current
implementation. I agree that consideration is nonsense, though ;)
So, to address the problem: What functions are bound to the ebuild
rather than ebuild.sh?
Beside {use,has}{,v} I don't know any.
Further, all of these are still overridable by *bashrc and env.
How?
Actually it doesn't fail sourcing.
Yeah, my bad. But you'd get a nice error message at least ;)
Drop the readonly crap; it's not actually blocking anything, just
attempting to catch non real issues; in the process, it actually is a
step in the wrong direction.
I will drop it for now, but I would like to know the answers to above
questions nevertheless.
Reordering is a bit arbitrary, but fine. Attempted env changes, would
avoid those.
My primary goal is to cut down ebuild.sh to a managable size. I don't
see how that can be solved with a different env handling, tbh.
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 developer
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
Brian Harring wrote: You're asking on the wrong ml. Profile monkeying really should include a run through of -dev, *especially* something like that that's going to be a pita to turn off when folks start abusing it... Make sure you explicitly state that one *must not* force a flag simply because a build breaks with USE=-foo. Other than that, I'm for it. It will make my job easier :) -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
Paul Bredbury wrote: But it is not an error. The answer is known to be False, through the application of logic. No. Let's get really sophisticated and do the 'application of logic' step. There is a function built_with_use(). That function reports whether something was built with or without a specific USE flag. The sentence above includes the fragment 'was built with or without'. So it was built. Uh, oh, but it wasn't built!!?!? - Error Really. Go find a mathematician and discuss this matter with him. Tell him what you told me, and he will slap you with a large frying pan. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] per-package use.mask (bug 96368)
Zac Medico wrote: Shall we go ahead with the package.use.mask implementation or not? Yes, please! -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Re: Atom matching behavior
Brian Harring wrote: Response to this is that well don't have versions like that, which while valid, is ignoring the point- cpvs are exact in their version specification, there isn't anything implicit about them. This sounds to me like 'division through zero doesn't make sense, but i've still got the right to do it'. Really, if anybody is ever going to release 1.0 and 1.0.0 along each other, that person is completely on crack. You can't do 2/0, either can you have 1.0 and 1.0.0 being different versions. They should be the same. That being said, which one is higher? Tag on a (.0)* implicitly, you open up potential issues like above. Nonissue, really. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] feature freeze for 2.1
Zac Medico wrote: the addition of new features. From this time forward, please do not commit anything to the 2.1 branch (current trunk) unless it is a fix for functionality that already exists. Thank you in advance for your cooperation. Why don't we make 2.1 a real branch and use trunk for 2.2? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Stablizing portage 2.1
Zac Medico wrote: Well, it's been the tree for 2 days now we'll surely get bug reports as soon as people run into these hypothetical issues (though I expect very few, if any regressions). I think the globals cleanup is worth having in 2.1 because it makes the code more maintainable. Ack. If you want to move back to a more stable revision, I'd suggest 2.1_pre7 (before manifest2). I believe manifest2 introduced more potential for regressions than the globals cleanup did. I think we should really include Manifest2 in 2.1. So my personal favourite is pre10. I don't think Zac's cleanup will introduce many bugs, and if there are any, it should be pretty easy to fix them. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Breakout etc-update, dispatch-conf
I'm all for it. How about 'virtual/config-manager'? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Outstanding decisions
Next bunch of bugs that need a decision: Bug: portage: emerge unmerge ... should stop in case of an error http://bugs.gentoo.org/show_bug.cgi?id=118515 Another WONTFIX/WILLFIX issue Bug: need a way to package.unmask packages in profiles http://bugs.gentoo.org/show_bug.cgi?id=118440 Is this LATER? Alec mentioned a patch, but i couldn't find it when grepping through my archives, and nothing is attached to the bug. Bug: emerge/ebuild - a bit more verbosity please http://bugs.gentoo.org/show_bug.cgi?id=67892 This obviously lacks any discussion. RFC :) Bug: Support for src_test deps required http://bugs.gentoo.org/show_bug.cgi?id=69021 WONTFIX/WILLFIX? Bug: no documentation on the elog functions http://bugs.gentoo.org/show_bug.cgi?id=116018 AFAICS it's documented in make.conf.example and man make.conf, but the user requested a howto. Is a howto really needed? IMHO it's not that complex... Bug: Split CONFIG_PROTECT into separate installing and uninstalling options (nuke untouched files) http://bugs.gentoo.org/show_bug.cgi?id=8423 The classical one with a huge CC list. Whatever decision is made, this finally needs to get (fixed and) closed. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Outstanding decisions
Hey all, I'm just wading through a list of ~200 bugs of which some need decisions what should be done, whether it should be done at all or simply whether it is a bug or not. Bug: SRC_URI: spaces not supported http://bugs.gentoo.org/show_bug.cgi?id=102607 Is this a 'NOTABUG' case? Bug: gpg: strict incorrectly takes priority over severe http://bugs.gentoo.org/show_bug.cgi?id=68906 What's the expected behaviour? Is it NOTABUG? Bug: Method to monitor a package without installing/upgrading it http://bugs.gentoo.org/show_bug.cgi?id=47456 Same thing. Do we want this? Bug: Support for a pre-compile pkg_config http://bugs.gentoo.org/show_bug.cgi?id=99529 As Jason mentioned: Is this worth the effort? Bug: per profile package.keywords http://bugs.gentoo.org/show_bug.cgi?id=55321 Voting seems to be a bit... incomplete ;) Bug: Wording These are the packages that I would merge, in order: http://bugs.gentoo.org/show_bug.cgi?id=112439 This needs a decision too. What wording do we prefer? Either way, the bug should be closed, the fix is trivial in case we want to change it. Bug: global exception handling http://bugs.gentoo.org/show_bug.cgi?id=28535 Should tracebacks be thrown in the users' face or not? Bug: /usr/lib/portage/bin/clean_locks documentation example could make use use DISTDIR http://bugs.gentoo.org/show_bug.cgi?id=116676 Call portageq or not? Voting time ;) That should be enough for the moment. More will probably follow, considering that I only checked the first 60 bugs or so :/ It would be nice if we could make the needed decision and then close the bugs where it is NOTABUG/INVALID/LATER. I hate stale bug listings ;) -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] should we add userpriv and usersandox to make.globals FEATURES?
Zac Medico wrote: What do people think about adding userpriv and usersandox to make.globals FEATURES? I've been using these for a long time and haven't had any trouble with them. Are there any arguments against making them default? I didn't verify this personally, but a few days ago mkay came to #g-portage and asked whether FEATURES='usersandbox -sandbox' resulting in sandbox enabled is expected behaviour or not. Before we add usersandbox to the default FEATURES we should make sure that -sandbox always disables sandbox. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] emaint and handling of user editable files
Christian Hoenig wrote: On the other hand it would be very nice to allow comments in the world file, too, as I very often don't remember why I installed a package (a lib which for example was just a dependency for lokaly installed stuff). As I'm writing this I get the idea, that this probalby should not be part of the world file but of portage itself with a --comment TEXT parameter :-). That sounds awkward. Why introduce a new option to portage if you could just fire up your preferred text editor and create a whyiinstalledthisstuff file? Really, this is not the purpose of a package manager IMO. So, finally, how should emaint --fix deal with comments in files? (a) Only give a recommendation what / how to fix? (b) Fix if there are no comments contained, otherwise only do (a)? (c) make emaint --fix comment the lines out instead of removing them entirely. That way, you could just ignore comments and it would be a lot safer too.. I simply don't like the idea very much of having a tool removing lines from my config files. You could use ## or #@ (or whatever) to comment the lines out, which should be easy to recognize for the user. It would take a few seconds to cut the lines starting with said prefix out of the file, and the user could remove old comments in the same go. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Improved user information and communication
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 [EMAIL PROTECTED] -- gentoo-portage-dev@gentoo.org mailing list
