Discussion:
[gentoo-dev] How help in arch testing work
(too old to reply)
Agostino Sarubbo
2012-01-18 14:30:02 UTC
Permalink
This mail is come from my long time experience about testing.

So, everytime, I must suggest the same things and I can say that at some point
it gets boring.

I appreciate the work of all, but I must say that some people pay little
attention to stablereq bugs, so this mail wants to be a short reminder of what
could decrease our work.

1) There is a discussion[1] about it, but for the moment, a stablereq should
be "keywording and stabilization" and enhancement importance.
If you need to accelerate the stabilization please set high and not from
enhancement to critical and so on.
Don't forget STABLEREQ keyword or the bug will not appears in our list.

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

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.

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.
So you can lighten our work in 2 ways:
a) Please rebuild the following list of rdepends.( if no need to rebuild all
because maintainer already do it)
b) Please rebuild all rdepends.
So, unfortunately, I don't know a rapid way to have only a stable list of
packages, so if really there isn't it, is very very appreciated print the list
of packages that needs rebuild
Sorry in advance if there is and I'm ignoring it, please tell me.



I want to point out that this is not a polemic, but is a way to suggest what
you can do for arch teams to increase the quality of teamwork and do not waste
precious time.


[1]: https://bugs.gentoo.org/show_bug.cgi?id=381627
[2]: qlist -e portage | grep ebuild-helpers
[3]: amd64box ~ # cat /usr/local/bin/scan
#!/bin/bash
qlist -e "$@" | xargs scanelf -L -n -q -F '%n #F' | tr , ' ' | xargs qfile -Cv
| sort -u | awk '{print $1}' | uniq
--
Agostino Sarubbo ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D
Tobias Klausmann
2012-01-18 14:50:01 UTC
Permalink
Hi!
Post by Agostino Sarubbo
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
Alexis Ballier
2012-01-18 15:00:02 UTC
Permalink
Hi,

On Wed, 18 Jan 2012 15:23 +0100
Post by Agostino Sarubbo
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
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.
Post by Agostino Sarubbo
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.
Rich Freeman
2012-01-18 15:50:01 UTC
Permalink
Post by Alexis Ballier
On Wed, 18 Jan 2012 15:23 +0100
Post by Agostino Sarubbo
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
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...
Post by Alexis Ballier
Post by Agostino Sarubbo
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
Mike Frysinger
2012-01-18 16:50:02 UTC
Permalink
Post by Rich Freeman
Post by Alexis Ballier
Post by Agostino Sarubbo
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
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
would help to reduce churn down the road as we try to minimize the
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
Rich Freeman
2012-01-18 18:50:01 UTC
Permalink
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
Mike Frysinger
2012-01-18 20:10:02 UTC
Permalink
Post by Rich Freeman
Post by Mike Frysinger
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
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.
Post by Rich Freeman
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
Rich Freeman
2012-01-18 20:50:01 UTC
Permalink
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
Duncan
2012-01-19 02:30:01 UTC
Permalink
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.
For years I had openssh in package.provided, since I literally did not
have a use for it at all. Then portage changed something and that didn't
work, so I had it added as a negative dependency in packages (where
busybox and module-init-tools are now, since I don't need either, all
modules built-in so no module-loading needed and I have a full backup
system install image copied over and test-booted for verification as my
rescue image so no rescue shell needed, and I never could get busybox to
build back when I used to try, until I gave up as no need for it anyway).

But when I got the netbook setup with the build chroot on the main
system, I installed ssh to handle secure rsyncing and remote admin from
my main system. So THEN I needed it and simply deleted the negative
dependencies.

But I STILL argue that ssh doesn't belong in @system. It's as optional
and special-purpose as X is, and xorg isn't in system. If people want
it, they can merge it, just like any other package. Really, the same
applies to busybox, and arguably, even to module-init-tools (and the more
recent replacement, kmod...), since that's not needed if people choose to
build all their drivers into the kernel.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Mike Frysinger
2012-01-19 16:50:02 UTC
Permalink
Post by Duncan
If people want
it, they can merge it, just like any other package. Really, the same
applies to busybox, and arguably, even to module-init-tools (and the more
recent replacement, kmod...), since that's not needed if people choose to
build all their drivers into the kernel.
not really. the # of people who build their kernel without module support is
such a minority that they can suck it up and accept the additional dep, or
simply use one of the many existing knobs in /etc/portage/ to disable it.

busybox is there because we believe Gentoo should have a rescue shell
installed for when the system/user eats things and needs recovery without
resorting to a livecd. if you never make a mistake, then you're free to
ignore it like anything else.
-mike
Duncan
2012-01-20 00:20:02 UTC
Permalink
Post by Mike Frysinger
If people want it, they can merge it, just like any other package.
Really, the same applies to busybox, and arguably, even to
module-init-tools (and the more recent replacement, kmod...), since
that's not needed if people choose to build all their drivers into the
kernel.
not really. the # of people who build their kernel without module
support is such a minority that they can suck it up and accept the
additional dep, or simply use one of the many existing knobs in
/etc/portage/ to disable it.
That's why I said "arguably, even..." for the kernel modules suggestion.
I wasn't seriously making that argument, only stating that it could be
made.
Post by Mike Frysinger
busybox is there because we believe Gentoo should have a rescue shell
installed for when the system/user eats things and needs recovery
without resorting to a livecd. if you never make a mistake, then you're
free to ignore it like anything else.
Having other recovery arrangements (like the mentioned system backup
partition, reachable with a simple alternate root= on the command line)
!= never make a mistake! In fact, it's precisely because I'm all too
aware of the possibility of my own fat-fingering (or neural short-
circuiting) as well as recognition of the fact that I DO run ~arch and
even masked packages (like the live-git openrc-9999) that I set it up
that way, the rootbak solution being at once both FAR more resilient than
a busybox after all still installed on the same working partition that
we're assuming now has major faults of an unspecified type, thus
triggering the emergency in the first place, AND far more flexible, since
the rootbaky solution has all of the same tools in the same configuration
as the user was using at the time the backup took place. So if (as
happened to a famous LWN editor at one point) an in-hindsight unwise
system update shortly before a conference where an important presentation
was to be made breaks the working installation, simply boot to rootbak
instead, and do the presentation using a snapshot of the system taken
when it was known to be working say a month or two earlier.

Busybox installed on a broken partition isn't going to help; neither will
busybox alone allow you to do your presentation coming up in 15 minutes,
if it's going to take 30 minutes of hacking to find and fix the problem.
Simply rebooting to a tested working rootbak snapshot of the system made
when it WAS working, using an alternate root= on the kernel command line,
allows both, and a single root= change in grub is going to be far easier
than working in an unfamiliar busybox environment, as well.

Of course, that implies changes to the handbook, etc, to encourage users
to setup their rootbak partition (partitions, if /usr and /var are on
separate partitions), and to periodically update AND TEST the rootbak
system snapshot(s), when the system is known to be in a reasonably stable
state.

But still, openssh is certainly the low hanging fruit, here, busybox less
so and not at all as long as it remains the recommended and default
emergency solution, and module-init-tools/kmod is only included as an
example of an excludeable should we REALLY want to get strict with
@system.

Meanwhile, the great thing about Gentoo is that it provides mechanisms
such as /etc/portage/profile/packages for users who wish to, to make such
changes on their own. On that I'm quite sure pretty much everyone here
can agree, or we'd not be here discussing it in the first place! =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Mike Frysinger
2012-01-19 03:10:01 UTC
Permalink
Post by Rich Freeman
Post by Mike Frysinger
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.
Post by Rich Freeman
Post by Mike Frysinger
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
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 ?
Post by Rich Freeman
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
Post by Rich Freeman
Basically what I'm advocating is that somebody shouldn't have to
*DEPEND. Future maintainers are welcome to undo the work of previous
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
Mike Gilbert
2012-01-19 03:50:01 UTC
Permalink
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.
Ian Stakenvicius
2012-01-19 16:50:02 UTC
Permalink
On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger
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)
Mike Frysinger
2012-01-19 17:10:02 UTC
Permalink
Post by Mike Gilbert
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
Rich Freeman
2012-01-19 14:10:02 UTC
Permalink
Post by Mike Frysinger
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
Mike Frysinger
2012-01-19 17:10:03 UTC
Permalink
Post by Rich Freeman
Post by Mike Frysinger
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.
Post by Rich Freeman
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
Agostino Sarubbo
2012-01-18 22:30:01 UTC
Permalink
Post by Alexis Ballier
Post by Agostino Sarubbo
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
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
Post by Alexis Ballier
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 Sarubbo ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D
Christian Faulhammer
2012-01-21 20:30:01 UTC
Permalink
Hi,
Post by Alexis Ballier
Post by Agostino Sarubbo
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.
To stick with the Emacs example: We barely use all those packages we
maintain. So sometimes we do not even execute this documented
test plan ourselves. Of course it only contains a small subset of
everything, but some test plans contain a "fool around with the
program" and it is better than nothing.

V-Li
--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>
Mike Frysinger
2012-01-18 15:10:02 UTC
Permalink
Post by Agostino Sarubbo
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
Post by Agostino Sarubbo
3) Check your rdepend, where is possible with scanelf[3] and if you declare
portage generates a NEEDED file in the vdb
Post by Agostino Sarubbo
4) Nobody knows how work all packages in tree, so there are obvious
sounds like a candidate for metadata.xml
-mike
Donnie Berkholz
2012-01-18 15:50:01 UTC
Permalink
Post by Mike Frysinger
Post by Agostino Sarubbo
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
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/>
Paweł Hajdan, Jr.
2012-01-18 17:40:03 UTC
Permalink
Post by Donnie Berkholz
Post by Mike Frysinger
Post by Agostino Sarubbo
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
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?
Mike Frysinger
2012-01-18 18:20:02 UTC
Permalink
Post by Paweł Hajdan, Jr.
Post by Donnie Berkholz
Post by Mike Frysinger
Post by Agostino Sarubbo
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
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
Paweł Hajdan, Jr.
2012-01-18 18:20:02 UTC
Permalink
Post by Mike Frysinger
Post by Paweł Hajdan, Jr.
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.
Markos Chandras
2012-01-18 19:10:01 UTC
Permalink
Post by Paweł Hajdan, Jr.
Post by Donnie Berkholz
Post by Mike Frysinger
Post by Agostino Sarubbo
3) Check your rdepend, where is possible with scanelf[3] and
if you declare it, please, as you said, exclude gcc/glibc and
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
Mike Frysinger
2012-01-18 20:10:02 UTC
Permalink
Post by Markos Chandras
Post by Paweł Hajdan, Jr.
Post by Donnie Berkholz
Post by Mike Frysinger
Post by Agostino Sarubbo
3) Check your rdepend, where is possible with scanelf[3] and
if you declare it, please, as you said, exclude gcc/glibc and
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
Michael
2012-01-19 09:00:02 UTC
Permalink
Post by Mike Frysinger
Post by Markos Chandras
Post by Paweł Hajdan, Jr.
Post by Donnie Berkholz
Post by Mike Frysinger
Post by Agostino Sarubbo
3) Check your rdepend, where is possible with scanelf[3] and
if you declare it, please, as you said, exclude gcc/glibc and
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
Although it does not make use of the newly-discovered NEEDED file, I
wrote a tool a while back that checks scanelf output against RDEPEND:
https://github.com/kensington/gentoo-tools/blob/master/missingdep.sh
Paweł Hajdan, Jr.
2012-01-27 09:50:02 UTC
Permalink
[...]
Post by Agostino Sarubbo
5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree
!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).
Thomas Kahle
2012-01-27 09:50:02 UTC
Permalink
On 15:23 Wed 18 Jan 2012, Agostino Sarubbo wrote:
[...]
Post by Agostino Sarubbo
5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree
!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/
Continue reading on narkive:
Loading...