Re: [gentoo-dev] How help in arch testing work
On 15:23 Wed 18 Jan 2012, Agostino Sarubbo wrote:
[...]
5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree
and an easy way to check the list of rdepend is asking our bot:
!rdep ${package}
Unfortunately it prints a complete list of RDEPEND(stable+testing), and is a
lack of time checking manually what is the list of stable packages.
Can be done easily with some eix scripting. app-portage/tatt has this
implemented too.
Cheers,
Thomas
--
Thomas Kahle
http://dev.gentoo.org/~tomka/
signature.asc
Description: Digital signature
Re: [gentoo-dev] How help in arch testing work
On 1/27/12 10:41 AM, Thomas Kahle wrote:
On 15:23 Wed 18 Jan 2012, Agostino Sarubbo wrote:
[...]
5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree
and an easy way to check the list of rdepend is asking our bot:
!rdep ${package}
Unfortunately it prints a complete list of RDEPEND(stable+testing), and is a
lack of time checking manually what is the list of stable packages.
Can be done easily with some eix scripting. app-portage/tatt has this
implemented too.
And my arch-tools also has a script for that (reverse-dependencies.py).
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] How help in arch testing work
On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger vap...@gentoo.org wrote: if it's part of the implicit system dep, they absolutely need to defend their actions. you want to change the policy, then start a thread on it. What policy? I don't see any written policy stating that you aren't allowed to include system packages in *DEPEND. There is a line in the devmanual stating that it is not necessary, nor advisable,... to list some kinds of system dependencies, full of caveats about the system set varying by profile and specific versions and such. It does not say that it is not permitted. So, I don't really see any policy to change. Anybody wanting to create such a policy is of course welcome to start a thread on it... :) Rich
Re: [gentoo-dev] How help in arch testing work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/01/12 10:41 PM, Mike Gilbert wrote: On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger vap...@gentoo.org wrote: - you're confusing the literal @system with implicit system deps I don't quite follow here. literal @system = the exact packages listed in the 'system' package list implicit deps = packages installed as part of the system due to dependency resolution (including via use flags or whatnot and/or default settings from the profile) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk8YSBMACgkQAJxUfCtlWe0LlAEAnSzthcxjk3BAFJSrYysjtiUl mfQw1TMZ4wxcLgxJtQAA/jjquypoUwjCCJhwEYSNPM5dRHu3jNhapVfN2+8H32AF =4LFJ -END PGP SIGNATURE-
Re: [gentoo-dev] How help in arch testing work
On Thursday 19 January 2012 09:04:08 Rich Freeman wrote: On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger vap...@gentoo.org wrote: if it's part of the implicit system dep, they absolutely need to defend their actions. you want to change the policy, then start a thread on it. What policy? I don't see any written policy stating that you aren't allowed to include system packages in *DEPEND. we've always avoided depending on implicit system packages. the devmanual was the first attempt and writing it down, but it doesn't change the history no matter how much you want otherwise. the exact package list has been refined over time to shrink things down, but it hasn't change the policy. There is a line in the devmanual stating that it is not necessary, nor advisable,... to list some kinds of system dependencies, full of caveats about the system set varying by profile and specific versions and such. It does not say that it is not permitted. considering all the packages listed have known conflicts for other profiles, it is an error for you to attempt to include it. and as already stated, doing it is just in my packages doesn't fly as crap spreads. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
On Wednesday 18 January 2012 22:41:26 Mike Gilbert wrote: On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger wrote: - you're confusing the literal @system with implicit system deps I don't quite follow here. By implicit system deps, are you referring to the common sense set of essential packages that you have floating around in that brain of yours? :) this policy predates me, and i'm not the only one supporting it (i've had almost no hand in the construction of any part of the devmanual for examle). i might have a pretty good idea of what things entail now, but that's purely a matter of me staring at the guts of the core system for so long. at this point, things can probably be enumerate a bit more clearly due to the slow culling of less important packages from @system. i'd have to noodle. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
Hi!
On Wed, 18 Jan 2012, Agostino Sarubbo wrote:
4) Nobody knows how work all packages in tree, so there are
obvious packages like a browsers, IM, audio player,that is easy
decide if is ok or not, but there are also packages that an
Arch tester has never seen, so is a lack of time everytime
google about it or ask to maintainer, so, please specify what
test you want for this package; e.g.
-only compile test
-compile test and make sure src_test goes well
-make sure /usr/bin/${foo} works properly in ${that} manner
-see 5) about library
So, you can write one time 'how to' and copy/paste for the
future stablereq; I guess I'm not asking a long and difficult
task.
I'd like to point out that the Emacs people have a very nifty
list of how to test our stuff:
http://overlays.gentoo.org/proj/emacs/wiki/test%20plans
If you want to be an awesome maintainer, have something like this
for the archtesters, especially for the more obscure packages as
Agostino pointed out.
Regards,
Tobias
Re: [gentoo-dev] How help in arch testing work
Hi,
On Wed, 18 Jan 2012 15:23 +0100
Agostino Sarubbo a...@gentoo.org wrote:
2) _Before_ filing a request, please run repoman full, to be sure
that there is nothing to fix, then take a look at the ebuild and make
sure your ebuild have a minimum of QA; all external binary called in
the ebuild(sed, mv, cp, ln, rm, and so on) should have 'die'; if you
don't use EAPI4, make sure that all portage helper[2] have also '||
die'.
3) Check your rdepend, where is possible with scanelf[3] and if you
declare it, please, as you said, exclude gcc/glibc and all package
from @system
imho this has nothing to do with stabilization, every single package
should have these 2 points addressed.
however, fact is that a second pair of eyes reviewing the ebuild (which
is what arch testers usually do) usually spots more than the author.
there are obvious problems (reports from repoman) that indeed
should be fixed before asking for stabilization, but others are more
difficult to spot (automagics, missing die's/typos), and, as a
maintainer, the reviewing done by arch testers is usually a good help.
4) Nobody knows how work all packages in tree, so there are obvious
packages like a browsers, IM, audio player,that is easy decide if is
ok or not, but there are also packages that an Arch tester has never
seen, so is a lack of time everytime google about it or ask to
maintainer, so, please specify what test you want for this package;
e.g. -only compile test
-compile test and make sure src_test goes well
-make sure /usr/bin/${foo} works properly in ${that} manner
-see 5) about library
So, you can write one time 'how to' and copy/paste for the future
stablereq; I guess I'm not asking a long and difficult task.
what i dislike in this approach is that arch testers will follow a
test plan which the maintainer has obviously tested before and knows
it works.
sending people into the jungle of 'try to do something with $pkg' may
make them encounter problems the maintainer hadnt thought about.
Regards,
Alexis.
Re: [gentoo-dev] How help in arch testing work
On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote: So, everytime, I must suggest the same things and I can say that at some point it gets boring. so put it into a Gentoo guide and refer people to that 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system portage generates a NEEDED file in the vdb 4) Nobody knows how work all packages in tree, so there are obvious sounds like a candidate for metadata.xml -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
On Wed, Jan 18, 2012 at 9:55 AM, Alexis Ballier aball...@gentoo.org wrote: On Wed, 18 Jan 2012 15:23 +0100 Agostino Sarubbo a...@gentoo.org wrote: 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system imho this has nothing to do with stabilization, every single package should have these 2 points addressed. True, although unless I'm missing something I don't see the harm in listing packages as (R)DEPENDS that are in @system. If anything this would help to reduce churn down the road as we try to minimize the system set. If including packages from @system does break things like stage3s I'll rescind my remarks, but my impression is that all the circular deps necessitated some level of hard-coding in the scripts already... So, you can write one time 'how to' and copy/paste for the future stablereq; I guess I'm not asking a long and difficult task. what i dislike in this approach is that arch testers will follow a test plan which the maintainer has obviously tested before and knows it works. sending people into the jungle of 'try to do something with $pkg' may make them encounter problems the maintainer hadnt thought about. Yes and no. First, maintainers often run ~arch packages with ~arch dependencies. They are also likely to test on one of x86/amd64, but not both, or perhaps only in a 32-bit chroot where stuff like init scripts isn't really running/etc. Arch teams should be testing on stable systems running consistently on the same arch (no chroots, minimal package.keywords, etc). Arch teams due to dumb luck are also likely to be running different USE flags. So, I don't consider repeating tests as a real waste (trust me, at work I'm all over this sort of thing as we waste a lot of time running tests we know will pass due to NIH syndrome). Also, a maintainer might be able to suggest things that are more likely to break, or which are more likely to cause their users pain. If some aspect of a package is more fragile, then pointing that out to a tester is a good thing. No harm in having the arch team bumbling about a little, but unless a package is perceived as being fairly important I suspect most won't do a great deal of this. All that said, this is Gentoo - if you want a distro with 3 releases per year with coordinated beta cycles where everything is tested together, look elsewhere. Without doing this sort of thing we're going to have to accept that bugs are more likely to crop up (but will likely be fixed faster when they do) - release somewhat early, release very often is a pretty good summary about what we're about. Rich
Re: [gentoo-dev] How help in arch testing work
On 10:05 Wed 18 Jan , Mike Frysinger wrote: On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote: 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system portage generates a NEEDED file in the vdb Awesome, never seen that before! -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgp3cdeT1u02G.pgp Description: PGP signature
Re: [gentoo-dev] How help in arch testing work
On Wednesday 18 January 2012 10:44:44 Rich Freeman wrote: On Wed, Jan 18, 2012 at 9:55 AM, Alexis Ballier wrote: On Wed, 18 Jan 2012 15:23 +0100 Agostino Sarubbo wrote: 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system imho this has nothing to do with stabilization, every single package should have these 2 points addressed. True, although unless I'm missing something I don't see the harm in listing packages as (R)DEPENDS that are in @system. If anything this would help to reduce churn down the road as we try to minimize the system set. If including packages from @system does break things like stage3s I'll rescind my remarks, but my impression is that all the circular deps necessitated some level of hard-coding in the scripts already... it isn't just circular deps. it's also about breaking alternatives and useless bloat. adding coreutils to their depend because they execute `mv`, or sed because they execute `sed`, etc... is absolutely pointless. same goes for virtual/libc or virtual/os-headers. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
On 1/18/12 4:48 PM, Donnie Berkholz wrote: On 10:05 Wed 18 Jan , Mike Frysinger wrote: On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote: 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system portage generates a NEEDED file in the vdb Awesome, never seen that before! Same here. How about adding some warning to portage (maybe just in the developer profile) when files in NEEDED are provided by packages not in RDEPEND? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] How help in arch testing work
On Wednesday 18 January 2012 12:32:08 Paweł Hajdan, Jr. wrote: On 1/18/12 4:48 PM, Donnie Berkholz wrote: On 10:05 Wed 18 Jan , Mike Frysinger wrote: On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote: 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system portage generates a NEEDED file in the vdb Awesome, never seen that before! Same here. How about adding some warning to portage (maybe just in the developer profile) when files in NEEDED are provided by packages not in RDEPEND? atm, we'll get a lot of false positives due to over-linking. the libtool + .la files issue is a general example. another one off the top of my head: a package uses GTK+, so it runs `pkg-config --libs gtk+-2.0`, and links against a lot more stuff than GTK+, but it doesn't list those deps itself, so it'd fail. we could extend the logic to assume anything not found in the pkg's RDEPEND, but was found in the full RDEPEND tree, is simply an implicit dep like that, but this quickly dilutes the usefulness i think :(. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
On 1/18/12 7:10 PM, Mike Frysinger wrote: On Wednesday 18 January 2012 12:32:08 Paweł Hajdan, Jr. wrote: Same here. How about adding some warning to portage (maybe just in the developer profile) when files in NEEDED are provided by packages not in RDEPEND? atm, we'll get a lot of false positives due to over-linking. the libtool + .la files issue is a general example. another one off the top of my head: a package uses GTK+, so it runs `pkg-config --libs gtk+-2.0`, and links against a lot more stuff than GTK+, but it doesn't list those deps itself, so it'd fail. we could extend the logic to assume anything not found in the pkg's RDEPEND, but was found in the full RDEPEND tree, is simply an implicit dep like that, but this quickly dilutes the usefulness i think :(. Oh, I meant the full RDEPEND tree in the above terminology. It's not perfect indeed, but should catch most serious errors. Also, we could make the direct RDEPEND problem a non-fatal warning. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] How help in arch testing work
On Wed, Jan 18, 2012 at 11:45 AM, Mike Frysinger vap...@gentoo.org wrote: it isn't just circular deps. it's also about breaking alternatives and useless bloat. adding coreutils to their depend because they execute `mv`, or sed because they execute `sed`, etc... is absolutely pointless. same goes for virtual/libc or virtual/os-headers. Perhaps pointless, but likely harmless as well. I wasn't suggesting that we should systematically add @system deps - only that we shouldn't systematically remove them either unless they cause harm. When I think about the use cases for reduced @system, I think that listing them in RDEPEND probably has more utility than having them in DEPEND. It usually matters more on minimal systems that the packages in the run state are smaller, and the build state often doesn't matter as much (consider something installed into a chroot using crossdev/etc). Coreutils is obviously an extreme example, although even that could be replaced by something like busybox. Then again, unless somebody makes a virtual for it I don't think that trying to put that in an RDEPEND gets us anywhere. Bottom line is that if somebody has a reason for sticking an @system package in (R)DEPEND I don't see the need to treat it as a bug, unless it actually causes harm beyond 30 more bytes in block tail space for something in /usr/portage. Just my two cents... Rich
Re: [gentoo-dev] How help in arch testing work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/18/2012 05:32 PM, Paweł Hajdan, Jr. wrote: On 1/18/12 4:48 PM, Donnie Berkholz wrote: On 10:05 Wed 18 Jan , Mike Frysinger wrote: On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote: 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system portage generates a NEEDED file in the vdb Awesome, never seen that before! Same here. How about adding some warning to portage (maybe just in the developer profile) when files in NEEDED are provided by packages not in RDEPEND? Interesting idea. I agree this has to be only in dev profile for now - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJPFxcpAAoJEPqDWhW0r/LCplgP/2EpRfImbWztFPoRN0gw3edC zhvSd0pQ8aVNSrT3A2f4abM0iigTtcrqLi2FoWAxxYOPrRFGftIKmLQVcRD82GFk 0CQtpDiQduEWozinSxITsp12lnvc/T0NDfnnLYRiys7+0t5FOdAsjceyR3+yObRL 3fFd5624n5PJoIISc82KFXs1WgKZhasf3XCxSaW7EAEKC4G9oxvTmGThCByUyyBf v6jv+qk3UEYN+gI46TDMRF+2aDoSKKU1Tmb5N/XgHhixPHFxPf7nmgIDLb0SGGuQ hlTLmQfsx9kVzGDdIdRl5ufuq2IjL0M0VUYP1qc5oiXh19SC2ddyIwMAQahLQEsL NlaOOH+vchUlfENbXSPK6VwmbPH55h966JQezNcj53+VkfJ1PRnTPeUoE35sPn4D aH++L7ioPog0jLKovRUYX+KRvjjQdLPuQe0t5V+f81yo1cjr13nL7o/ijfD6y/Me 9Vxr9kn/WwWQqlxzvb2UPtHYlFY+KbRnpGqh9bB4pP/y/dvEjcxjeNxxOGEHfIuP tqVSBt0S6e326tsMXIQhPtYcd0j1KB+DCN0sV8QZpAlVbnq0ZsS2YbT9ls+RQdKr 9ttgwwZ6FLJungqul1QDIUh0qorBROTjC0J6bTrCoANyv0qYOMeinPLB+dozZF4d /9M1VM3mnn5b/YVbnmYR =Mp6K -END PGP SIGNATURE-
Re: [gentoo-dev] How help in arch testing work
On Wednesday 18 January 2012 13:42:12 Rich Freeman wrote: On Wed, Jan 18, 2012 at 11:45 AM, Mike Frysinger wrote: it isn't just circular deps. it's also about breaking alternatives and useless bloat. adding coreutils to their depend because they execute `mv`, or sed because they execute `sed`, etc... is absolutely pointless. same goes for virtual/libc or virtual/os-headers. Perhaps pointless, but likely harmless as well. I wasn't suggesting that we should systematically add @system deps - only that we shouldn't systematically remove them either unless they cause harm. it is a problem. not all profiles use coreutils ... they provide replacement packages. busybox is just one example. the bsd/prefix guys go in even weirder directions. it also encourages people to add this crap to other packages, and gets us into an even more confusing state. people look at existing ebuilds as examples, and having things like grep or sed or coreutils sets an awful example. when i see these things in ebuilds, i make sure to scrub them when updating. When I think about the use cases for reduced @system, I think that listing them in RDEPEND probably has more utility than having them in DEPEND. It usually matters more on minimal systems that the packages in the run state are smaller, and the build state often doesn't matter as much (consider something installed into a chroot using crossdev/etc). Coreutils is obviously an extreme example, although even that could be replaced by something like busybox. Then again, unless somebody makes a virtual for it I don't think that trying to put that in an RDEPEND gets us anywhere. DEPEND usage is useless cruft to the point of absurdity. RDEPEND is much less common as then you're really only talking about the random shell scripts. i'd argue still though that it still doesn't make sense considering a system can hardly boot without coreutils. and if you are in a situation where you have such a reduced install that it can, the existing @system semantics work for you. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
On Wednesday 18 January 2012 14:02:01 Markos Chandras wrote: On 01/18/2012 05:32 PM, Paweł Hajdan, Jr. wrote: On 1/18/12 4:48 PM, Donnie Berkholz wrote: On 10:05 Wed 18 Jan , Mike Frysinger wrote: On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote: 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system portage generates a NEEDED file in the vdb Awesome, never seen that before! Same here. How about adding some warning to portage (maybe just in the developer profile) when files in NEEDED are provided by packages not in RDEPEND? Interesting idea. I agree this has to be only in dev profile for now would probably be easy to just whip up a tool that ran locally on all of the dev's installed packages ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
On Wed, Jan 18, 2012 at 3:01 PM, Mike Frysinger vap...@gentoo.org wrote: it is a problem. not all profiles use coreutils ... they provide replacement packages. busybox is just one example. the bsd/prefix guys go in even weirder directions. Yup - hence my point about coreutils not being a good one to include unless you virtualized it, which probably is more than we'd really want to do for a system package. DEPEND usage is useless cruft to the point of absurdity. RDEPEND is much less common as then you're really only talking about the random shell scripts. i'd argue still though that it still doesn't make sense considering a system can hardly boot without coreutils. and if you are in a situation where you have such a reduced install that it can, the existing @system semantics work for you. Again, you're using coreutils as an example, and that doesn't seem like something that would be much of a value-add to place in RDEPEND. However, if you had a package that required openssh, that would seem to be a much better candidate for an RDEPEND, since it is trivial to boot a system without openssh installed despite it being in system. Openssh is obviously a bit of a contrived example in the opposite direction, but it is in @system. Basically what I'm advocating is that somebody shouldn't have to defend their actions if they include something from @system in *DEPEND. Future maintainers are welcome to undo the work of previous maintainers as always. @system packages in *DEPEND should not be considered a bug (as long as they're right). Rich
Re: [gentoo-dev] How help in arch testing work
On Wednesday 18 January 2012 11:55:30 Alexis Ballier wrote: 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system imho this has nothing to do with stabilization There is a misunderstading about it. I did not mean what the other sayd. So, if is not clear, the goal should be: check your RDEPEND before filing stabilization. Stop what i dislike in this approach is that arch testers will follow a test plan which the maintainer has obviously tested before and knows it works. sending people into the jungle of 'try to do something with $pkg' may make them encounter problems the maintainer hadnt thought about. I think the same, but just for your info, there are, imho, few people that works in popular arches like x86/amd64 and is not possible because of missing of 'tester', imagine in arches like sparc/ia64 where only people like armin76 works =) -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
On Wednesday 18 January 2012 15:45:04 Rich Freeman wrote: On Wed, Jan 18, 2012 at 3:01 PM, Mike Frysinger wrote: it is a problem. not all profiles use coreutils ... they provide replacement packages. busybox is just one example. the bsd/prefix guys go in even weirder directions. Yup - hence my point about coreutils not being a good one to include unless you virtualized it, which probably is more than we'd really want to do for a system package. the virtual is irrelevant. it's noise regardless. DEPEND usage is useless cruft to the point of absurdity. RDEPEND is much less common as then you're really only talking about the random shell scripts. i'd argue still though that it still doesn't make sense considering a system can hardly boot without coreutils. and if you are in a situation where you have such a reduced install that it can, the existing @system semantics work for you. Again, you're using coreutils as an example, and that doesn't seem like something that would be much of a value-add to place in RDEPEND. a shell ? sed ? grep ? find ? awk ? which ? However, if you had a package that required openssh, that would seem to be a much better candidate for an RDEPEND, since it is trivial to boot a system without openssh installed despite it being in system. this is a bad example for many reasons: - there are already talks of getting rid of it (in favor of stage4/etc...) - this doesn't fall inline with our already long stated policy: http://devmanual.gentoo.org/general-concepts/dependencies/index.html - you're confusing the literal @system with implicit system deps Basically what I'm advocating is that somebody shouldn't have to defend their actions if they include something from @system in *DEPEND. Future maintainers are welcome to undo the work of previous maintainers as always. @system packages in *DEPEND should not be considered a bug (as long as they're right). if it's part of the implicit system dep, they absolutely need to defend their actions. you want to change the policy, then start a thread on it. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How help in arch testing work
On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger vap...@gentoo.org wrote: - you're confusing the literal @system with implicit system deps I don't quite follow here. By implicit system deps, are you referring to the common sense set of essential packages that you have floating around in that brain of yours? :) If so, it would save a lot of useless mailing list discussion if we could just write that list down once and for good. The devmanual specifically mentions the entire system target, which is logically interpreted as @system. If that's not the case, then lets clarify that policy.
