Re: [gentoo-dev] New global USE flags (network, 3dnowext, static-libs, mtp)
On K, 2009-06-03 at 02:13 +0300, Samuli Suominen wrote: USE network is used by 9 ebuilds, and one is using USE networking which can be converted, that'd be 10. USE 3dnowext is basic optimization, 3 ebuilds, but it should be with mmx and others. USE static-libs to enable or disable static libs (archives), used by 6 ebuilds, soon more. USE mtp is used by 6 ebuilds, enables Media Transfer Protocol support. Any objections? Could you share it with everyone what the proposed global descriptions of these USE flags would be, and what the individual local USE flag descriptions currently are? So that everyone won't need to look up by themselves or guess the global description. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] A new glep: Ebuild format and metadata handling
On Sun, 2009-05-31 at 15:56 +0200, Patrick Lauer wrote: Thank you for collecting this up! parsers: The current practise of putting the eapi definition near the top of the ebuild, combined with the need to state it for all non-EAPI0 ebuilds, suggests that it can be parsed without having to source the ebuild. Would it improve parsers' performance to explicitly define EAPI=0 in EAPI0 ebuilds too, so it always can find an EAPI value? haubi He proposes to use an eapi.eclass and define eapi as a function. Erm, unlike earlier I did not propose eapi as a function this time. Instead, my proposal is identical to the parsers one, but with a backwards compatible syntax for defining the EAPI value that allows to have non-parsing PMs (nearly) silently ignore the ebuild, so we do not have to wait another extended period (=year) to put parsed EAPI values in the tree after a parsing PM became stable. This backwards compatibility syntax is done with the eapi.eclass, which does nothing but early exit when inherit'ed by an old (=non-parsing) PM. It is up to the parsing PM (the PMS) if 'eapi.eclass' actually gets read in, as the implementation of 'inherit' is part of the PM and has to detect eapi as special argument anyway, otherways it would fail to find 4.eclass when used this way: inherit eapi 4 But I can also think of this syntax: EAPI=4# parsers read this line only inherit eapi# compat for non-parsing PM only Here the 'inherit eapi' line can be dropped as soon as we do not need to support non-parsing PMs any more. However, parsing PMs either need to ignore eapi as argument to 'inherit', or need to inform eapi.eclass somehow that the EAPI was parsed already. There might be a better name than 'eapi.eclass' here. With 'eapicompat.eclass' fex this would read: EAPI=4 inherit eapicompat Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Re: How not to discuss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Freeman wrote:
Steven J Long wrote:
Getting into a nonsensical debate about PN being metadata seems to be
the level of the argument, so forgive me for not being very impressed.
(It's externally derived and in fact the whole point of the product;
unless someone is proposing losing PN and PV from filename, can we
*please* dismiss that argument as the irrelevance which it is?)
Without actually intending to open a new debate on that issue cringes,
I'm actually a fan of NOT obtaining PN and PV from the filename. I've
seen an approach like this used in various systems and I happen to like it:
In which systems did you see this approach?
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkomU8YACgkQp/VmCx0OL2ym0QCfcbruFkqtUIBhdwhKIjaP9qol
Qi8An0TdECGv14pgMTmjdDhllvGylM7y
=1iV1
-END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
Nirbheek Chauhan wrote: I would like to kick-start the nominations by nominating Mart Raudsepp (leio), Petteri Räty (betelgeuse), and Luca Barbato (lu_zero) [all of them are CCed] Patrick Lauer wrote: * lu_zero, because he's done a good job and brings in his own ideas without going religious on people with different opinions I accept your nomination, thank you ^^ lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
[gentoo-dev] New metadata fields
I had an idea for some new fields to go in metadata.xml. Not sure if we would need a GLEP for this or not? Anyway, what do you guys think: Two things I can think of adding that would be useful: - ChangeLog URL - Bug Tracker I know I hate hunting down the two of them, and both of them could be useful references for developers and users. Plus, not every upstream has them, so they can of course be optional fields. Steve
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
2009/6/1 Dawid Węgliński c...@gentoo.org: On Monday 01 of June 2009 06:25:06 Jorge Manuel B. S. Vicetto wrote: Hello fellow developers and users. I nominate: peper Thank you, I accept. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] New eclass proposal: auto-export
On Wednesday 22 of April 2009 15:35:37 Petteri Räty wrote:
Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
of functions. This way all eclasses don't have to duplicate the EAPI
detection code. If people find this useful, I will document it properly
with eclass-manpages etc.
I like the idea, I'd have some feature request regarding it.
I'd like to have global eclass-wise EXPORT_FUNCTIONS variable introduced in
ebuilds (functions and variables can have identical names, bash handles it)
with list of allowed phases to export for all inherited eclasses.
It's needed in cases when eclass global scope is needed (for some setup for
example, setting SLOT etc) but overriding phases is not desired.
Currently it seems to be needed to override every not needed phase with dummy
phase_function() {
:
}
It means overriding all src_* phases if no ${S} is present.
With proposed solution, there would be for example:
in ebuild:
EXPORT_FUNCTIONS=pkg_setup pkg_postinst pkg_postrm
inherit kde4-base
[...]
in eclasses there would be autoexport code
autoexport.eclass would need to be tweaked to export only those defined phases
that are listed in EXPORT_FUNCTIONS if EXPORT_FUNCTIONS is not empty
That would disable overriding not wanted phases all way down (provided all
eclasses all way down use autoexport that is).
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
On Wed, Jun 3, 2009 at 1:22 AM, Mounir Lamouri volk...@gentoo.org wrote: Nirbheek Chauhan wrote: Most licenses aren't for usage, but for distribution -- surely you mean EULAs? License and EULA is the same for most users and it's exactly the same for ebuilds/portage. EULA is an End-User license agreement, and is to be agreed upon by the *user*. Not the person installing the program. This means they're (or should be) prompted at first start-up, not at install. If they're prompted at install, it's broken. I don't get your point. check_license() is used to print the license (it's probably only used for EULA's actually) and wait for user approval before resume the merge process. The printed license is the license from LICENSE var. Since they're prompted at install, *that* behaviour needs to be changed, not worked around. It should be prompted for every user, probably by using a config file in ~/.config/eulas + a wrapper which checks for the EULA having been accepted. -- ~Nirbheek Chauhan
Re: [gentoo-dev] New metadata fields
The equery 'meta' module in gentoolkit-0.3.0* can show all the upstream fields, though not many packages currently make use of it. Oh yeah, and there's a traceback in the upstream code that's been fixed but won't be in the tree until rc7, so you may want to wait to check it out. $ equery m --upstream lince * net-p2p/lince Remote ID: sourceforge: lincetorrent
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
2009/6/1 Dawid Węgliński c...@gentoo.org: I nominate: [...] Calchan Thanks Dawid, and also Ferris. I accept. You can find my manifesto at http://dev.gentoo.org/~calchan/manifesto09/manifesto.html Denis.
Re: [gentoo-dev] New global USE flags (network, 3dnowext, static-libs, mtp)
Mart Raudsepp wrote: On K, 2009-06-03 at 02:13 +0300, Samuli Suominen wrote: USE network is used by 9 ebuilds, and one is using USE networking which can be converted, that'd be 10. USE network Enable networking support USE 3dnowext is basic optimization, 3 ebuilds, but it should be with mmx and others. USE 3dnowext Adds support for 3dnowext multimedia processor instructions (desc. almost copy from 3dnow desc) USE static-libs to enable or disable static libs (archives), used by 6 ebuilds, soon more. USE static-libs Build static libraries USE mtp is used by 6 ebuilds, enables Media Transfer Protocol support. USE mtp Enable support for Media Transfer Protocol Any objections? Could you share it with everyone what the proposed global descriptions of these USE flags would be, and what the individual local USE flag descriptions currently are? So that everyone won't need to look up by themselves or guess the global description. Thanks Samuli
Re: [gentoo-dev] New metadata fields
Jeremy Olexa wrote: On Wed, Jun 3, 2009 at 9:38 AM, Steve Dibb bean...@gentoo.org wrote: I had an idea for some new fields to go in metadata.xml. Not sure if we would need a GLEP for this or not? Anyway, what do you guys think: Two things I can think of adding that would be useful: - ChangeLog URL - Bug Tracker I know I hate hunting down the two of them, and both of them could be useful references for developers and users. Plus, not every upstream has them, so they can of course be optional fields. Steve mraudsepp pointed this out in irc (I didn't know about it either): http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=4 You are allowed to use changelog and bugs-to So...have fun ;) -Jeremy I think Jeremy just proposed to add these fields in metadata.xml gentoo-syntax template for vim. That's a great idea Jeremy, it will surely help more devs to fill these fields ! :) Mounir
Re: [gentoo-dev] New global USE flags (network, 3dnowext, static-libs, mtp)
Samuli Suominen wrote: Mart Raudsepp wrote: On K, 2009-06-03 at 02:13 +0300, Samuli Suominen wrote: USE network is used by 9 ebuilds, and one is using USE networking which can be converted, that'd be 10. USE network Enable networking support Maybe network and net could be merged ? Mounir
Re: [gentoo-dev] Re: How not to discuss
Marijn Schouten (hkBst) wrote: Richard Freeman wrote: Without actually intending to open a new debate on that issue cringes, I'm actually a fan of NOT obtaining PN and PV from the filename. I've seen an approach like this used in various systems and I happen to like it: In which systems did you see this approach? A bunch of proprietary systems that nobody here would have heard of (well, most likely). They had nothing to do with package management. The systems in question use a distinct field to display record names (which is user definable) and use separate fields to capture the content of the record. In many cases the contents of some of these separate fields end up in the informal record name field, but it is still desirable that they be distinct. Sorry if I implied that my example was directly related to gentoo or package management. I was extrapolating from a completely different field. However, I still think this is worth considering (entirely apart from glep55). If I were building a portage system from scratch I'd consider doing it this way. With all the history we have currently I'm not sure I'd be eager to make this change now (though I guess we actually could as part of a new EAPI).
Re: [gentoo-dev] New global USE flags (network, 3dnowext, static-libs, mtp)
Mounir Lamouri wrote: Samuli Suominen wrote: Mart Raudsepp wrote: On K, 2009-06-03 at 02:13 +0300, Samuli Suominen wrote: USE network is used by 9 ebuilds, and one is using USE networking which can be converted, that'd be 10. USE network Enable networking support Maybe network and net could be merged ? Mounir Yes. USE=networking and USE=net to global USE flag network. They all seem to do the same thing.
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
2009/6/2 Doug Goldstein car...@gentoo.org: All, The current council meetings have gotten completely out of hand for weeks meetings have become nothing more then a continuation of the senseless bicker-fest that have become the e-mail threads on GLEP54, GLEP55, and EAPI-3 without any real progress or sense coming of them. It's taken me a little bit to step up and put a stop to it but I fully intend on putting a stop to it. The point of the council meetings is to bring up a topic and decide on its merits whether it should be brought into the Gentoo Project or not. I quote from the first line of the Gentoo Council website: I am the author of both mentioned GLEPs but I don't feel too guilty about that. Council had every opportunity to decide upon them , one way or another, or state clearly that they don't like this or that. Instead, there has been a pointless discussion each time (4c comes to mind here). Imho, council should be less afraid to make difficult decisions. The elected Gentoo Council decides on global issues and policies that affect multiple projects in Gentoo. We have all collectively failed the Gentoo Project since we have not been doing this for the past several weeks. I propose the following changes be instituted before the meeting and happen through the meeting: 1) Agenda Topics are posted to the appropriate mailing lists at a MINIMUM 7 days prior to the meeting. (That means the agenda must be formed by this Thursday). 1a) Any changes to the agenda should be ACK'd by the council members (off list via the council alias). Changes can not occur less than 48 hours from the meeting. Sounds good, but I would still allow some flexibility even during the meeting if no-one objects. 2) The #gentoo-council channel become moderated as we had discussed several times in the past. 2a) Topics will be brought up and people wishing to address the council and the developer body at large should speak to the day's appointed moderator. We can take turns or I can do it (maybe it'll keep my head from banging against the keyboard as it has in the past watching the various non-council members argue completely non-agenda items back and forth). 2b) Requests are made in tells and honored in turn. The moderator will announce to the channel who wishes to speak and the order they are in and will efficiently work through the list. If you can not remain on topic, you will lose your voice. I wouldn't be so strict here, use it as last resort. 3) Once discussion on the topic has concluded, the council members will vote on the actions requested by the developer body. That does not mean it is time for council members to concoct an entirely new plan by the seat of their pants... which leads me to the next topic. ++ 4) Council members will now be expected to ACK the agenda on the appropriate mailing lists at least 48 hours prior to the meeting. If you can't, let the council know. You should be able to do this without relying on your proxy, but your proxy may do this for you as well if you have an extended away. 4a) Failure to ACK the agenda will be noted on the meeting minutes. 4b) Council members will be expected to formulate their thoughts in reply to the agenda items and to research the discussion they wish to have on the mailing list PRIOR to the meeting and not fly by the seat of their pants. 4c) The first I heard of this and I need 4 weeks to research this. or any variation of the quoted statement is no longer a valid statement. The point of the meeting is to weigh and debate the items before us now. Do your research PRIOR to the meeting, not during. 4c) is the most important imho. Also, I think meetings shouldn't be limited to 1 hour. I would move the limit to at least 2 hours. Even if the process is improved, 1 hour is just not enough. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
Hi Doug, I just got to this thread, so sorry for entering the debate a bit late. I find your propositions very interesting. In my manifesto [1] I have proposed something significantly different which simply consists in spinning the long discussions off the council meetings using more focused groups (see the GLEP process and Experts paragraphs). I personally think our two ideas are complementary and not competing against each others. Denis. [1] http://dev.gentoo.org/~calchan/manifesto09/manifesto.html
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Nirbheek Chauhan wrote: On Wed, Jun 3, 2009 at 1:22 AM, Mounir Lamouri volk...@gentoo.org wrote: Nirbheek Chauhan wrote: Most licenses aren't for usage, but for distribution -- surely you mean EULAs? License and EULA is the same for most users and it's exactly the same for ebuilds/portage. EULA is an End-User license agreement, and is to be agreed upon by the *user*. Not the person installing the program. This means they're (or should be) prompted at first start-up, not at install. If they're prompted at install, it's broken. I don't get your point. check_license() is used to print the license (it's probably only used for EULA's actually) and wait for user approval before resume the merge process. The printed license is the license from LICENSE var. Since they're prompted at install, *that* behaviour needs to be changed, not worked around. It should be prompted for every user, probably by using a config file in ~/.config/eulas + a wrapper which checks for the EULA having been accepted. I don't think EULA's have to be accepted by users when launching the program but when installing it. It's the way it's done in most cases in Windows and it has to be done because some EULA's add limitation on numbers of installations (mostly games). I admit End User should be the real user but you can't install a program if you do not agree to EULA in most cases. That's funny but some FOSS on Windows also prompt GPL to make sure the user accept it before installing. Mounir
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
Mike Frysinger wrote: This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Following Richard recommandation [1] I propose to vote for default ACCEPT_LICENSE value sets to: ACCEPT_LICENSE=* -...@eula with @EULA a license group including every licenses considered as EULA which means needing approval by user. This is including most commercial licenses. At least, every packages using check_license() from eutils.eclass should have their license add in @EULA group license. Why this default value ? My initial post [2] mentioned 3 values. I choose the one I described the worst because of issues reported. Indeed, Richard [3] reported he didn't want to have a too restrictive value. This one is the less restrictive we can have. In addition, Ciaran McCreesh reported an issue with badly licensed ebuilds like most X packages [4]. This issue was a blocker for a too restrictive default value. With the proposed value, bad licensed packages will not be blocked. At least, by default. Setting this default value as soon as possible is the best compromise. It will put this feature in portage and let people use it. Packages needing user approval will be blocked and then fix bug 152593 [5]. In addition, users setting ACCEPT_LICENSE to a more restrictive value will help to catch bad licensed ebuilds by filing bugs. Finally, it is removing a reason for interactiveness (via check_license()) into ebuilds. This could be a first step for a new default value in the future (when all licenses will be fixed). So, may the council vote on this default value for ACCEPT_LICENSE ? [1] can't find something in gmame nor in archives.g.o, you should add the year after the reminder for $month ;) [2] http://archives.gentoo.org/gentoo-dev/msg_d5c1e7285399ebc27a74bdd02cb4d037.xml [3] http://archives.gentoo.org/gentoo-dev/msg_f391139d825eb793cf0694add4f39d93.xml [4] http://archives.gentoo.org/gentoo-dev/msg_d5c1e7285399ebc27a74bdd02cb4d037.xml [5] https://bugs.gentoo.org/show_bug.cgi?id=152593 Thanks, Mounir
Re: [gentoo-dev] Re: RFC:sys-apps/portage @overlay atoms postfix support
2009/6/2 Duncan 1i5t5.dun...@cox.net: :: lacks that confusion. It does have the additional complication of needing quoted or escaped in the shell, but users are supposed to do a --pretend anyway, and after it doesn't output what's expected, a user of any shell experience at all should conclude with little delay that it /could/ be the escaping even if they aren't sure, and a quick suitably escaped trial will confirm it. Where/when does :: need escaping? -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
Denis Dupeyron wrote: In my manifesto [1] I have proposed something significantly different which simply consists in spinning the long discussions off the council meetings using more focused groups ++ I've seen this used to good effect on projects at work. The only challenge might be the fact that this works best when groups actually meet (as in everybody talking at the same time in the same place - or at least virtual place). Also - such working groups are not a substitute for community involvement. Usually the way these things happen are: 1. Topic is brought up. 2. Lots of people weigh in. 3. People volunteer to form a short-term team to work it out. 4. Team presents proposal. 5. Lots of people cheer (hopefully). 6. Oversight group (ie council) approves. This of course requires a team mentality at a few points along the process. Also - at work it helps that people without this kind of mindset get weeded out fairly quickly since the issue wouldn't be discussed if it weren't holding something up.
Re: [gentoo-portage-dev] Re: Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
On Sun, May 31, 2009 at 4:21 AM, Marijn Schouten (hkBst)
hk...@gentoo.org wrote:
Duncan wrote:
Patrick Börjesson psychoti...@lavabit.com posted
20090529201741.gb11...@nexon.nexus, excerpted below, on Fri, 29 May 2009
22:17:41 +0200:
Why exactly would you want to use --oneshot for a leaf package that is
not depended on by any other package in the world set? If spam IS
depended on by any other package (recursively) in the world set, it will
be pulled in by --complete-graph, but that's not the case here if i
understand it correctly, thus it's a package that you explicitly wanted
installed, thus it belongs in the world set, and you should thus not use
--oneshot for it.
I use -1 by default, here (via scriptlet), mainly so I don't have to
worry about cluttering up my world file while emerging individual
packages, just as I always use -NuD with my @system and @world runs.
But for leaf packages, it serves as a sort of test install as well.
Since I always do revdep-rebuild -p and emerge --depclean -p after every
update (typically 2-3 times a week), then rebuild and clean as I need to,
keeping the trial merges on the depclean list for a few days keeps me
aware of them. If I know it's something I want to keep, I run a
different scriptlet without the -1, but that's not often once a system is
up and running with the normal working set merged. Meanwhile, I
ultimately either emerge -C (or let depclean handle it) the trialware,
or emerge --noreplace, thus adding it to world.
But experimental installs and their deps typically sit in the --depclean
list for anything from a few minutes to a few days, until I decide
whether I want to keep or remove them.
If he was testing how the switches under discussion here worked and has a
similar policy, I could easily see him using -1 by habit, even if he
didn't explicitly reason that it was a test and therefore something he
didn't want in @world.
I think this is an interesting use-case. It would be very simple to handle it
by
introducing an additional file that the package manager would use to record
the
packages that are installed on trial-basis. This would make it possible to
include these packages in dep-calculations, while still distinguishing them
from
packages that are in @world. Of course you can also fake it by creating a
local
virtual/trialware package (or possibly a @trialware group) of which you edit
the
deps, but this would be less convenient. For my personal workflow using -1 for
trials is working well enough, atm.
Why is a custom set less convenient?
Well, instead of emerge --trialware package you would first have to edit your
@trialware set and then emerge @trialware. The same goes for when you want to
remove some trialware.
Perhaps some generalization of --trialware along the lines of
- --add-to-set=trialware could be fleshed out as a useful extension of portage.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkomWO8ACgkQp/VmCx0OL2wGHACfdlOdzvfLM3aUafiuOVQTlRnz
vvMAoMMeLUxnM2i8fpJhClxbsIqwMf3Z
=HSIG
-END PGP SIGNATURE-
Re: [gentoo-portage-dev] Re: Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marijn Schouten (hkBst) schrieb: Why is a custom set less convenient? Well, instead of emerge --trialware package you would first have to edit your @trialware set and then emerge @trialware. The same goes for when you want to remove some trialware. Perhaps some generalization of --trialware along the lines of --add-to-set=trialware could be fleshed out as a useful extension of portage. Marijn Well - and you also need to keep in mind to clean the set from time to time ... instead of just having a --depclean run - - René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkomzK8ACgkQ4UOg/zhYFuCSVACdF2/W736RnNJGs4/opSkl0Ggt Hw8An0ygC3opVGMXTVFqDD825IqpgbvL =BBip -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Re: Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan schrieb: Patrick Börjesson psychoti...@lavabit.com posted 20090529201741.gb11...@nexon.nexus, excerpted below, on Fri, 29 May 2009 22:17:41 +0200: Why exactly would you want to use --oneshot for a leaf package that is not depended on by any other package in the world set? If spam IS depended on by any other package (recursively) in the world set, it will be pulled in by --complete-graph, but that's not the case here if i understand it correctly, thus it's a package that you explicitly wanted installed, thus it belongs in the world set, and you should thus not use --oneshot for it. I use -1 by default, here (via scriptlet), mainly so I don't have to worry about cluttering up my world file while emerging individual packages, just as I always use -NuD with my @system and @world runs. But for leaf packages, it serves as a sort of test install as well. Since I always do revdep-rebuild -p and emerge --depclean -p after every update (typically 2-3 times a week), then rebuild and clean as I need to, keeping the trial merges on the depclean list for a few days keeps me aware of them. If I know it's something I want to keep, I run a different scriptlet without the -1, but that's not often once a system is up and running with the normal working set merged. Meanwhile, I ultimately either emerge -C (or let depclean handle it) the trialware, or emerge --noreplace, thus adding it to world. But experimental installs and their deps typically sit in the --depclean list for anything from a few minutes to a few days, until I decide whether I want to keep or remove them. If he was testing how the switches under discussion here worked and has a similar policy, I could easily see him using -1 by habit, even if he didn't explicitly reason that it was a test and therefore something he didn't want in @world. Well ... as one can probably see from the package names, I was just testing whether portage actually checks RDEPENDs of installed packages or not ;) (if it does not, Portato does not need to either ;)) And I often use -1 w/o even thinking about it - - René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkomzV8ACgkQ4UOg/zhYFuDyjACdHFOgdT8FABw/j4ta6aqutl7i 7X8AnjQvuHwY3iddJC5d0zRzv3PKoujL =WOYx -END PGP SIGNATURE-
