FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-18-2012, 03:45 PM
Mike Frysinger
 
Default 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
 
Old 01-18-2012, 04:32 PM
"Paweł Hajdan, Jr."
 
Default 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?
 
Old 01-18-2012, 05:10 PM
Mike Frysinger
 
Default 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
 
Old 01-18-2012, 05:15 PM
"Paweł Hajdan, Jr."
 
Default 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.
 
Old 01-18-2012, 05:42 PM
Rich Freeman
 
Default How help in arch testing work

On Wed, Jan 18, 2012 at 11:45 AM, Mike Frysinger <vapier@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
 
Old 01-18-2012, 06:02 PM
Markos Chandras
 
Default 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
zhvSd0pQ8aVNSrT3A2f4abM0iigTtcrqLi2FoWAxxYOPrRFGft IKmLQVcRD82GFk
0CQtpDiQduEWozinSxITsp12lnvc/T0NDfnnLYRiys7+0t5FOdAsjceyR3+yObRL
3fFd5624n5PJoIISc82KFXs1WgKZhasf3XCxSaW7EAEKC4G9ox vTmGThCByUyyBf
v6jv+qk3UEYN+gI46TDMRF+2aDoSKKU1Tmb5N/XgHhixPHFxPf7nmgIDLb0SGGuQ
hlTLmQfsx9kVzGDdIdRl5ufuq2IjL0M0VUYP1qc5oiXh19SC2d dyIwMAQahLQEsL
NlaOOH+vchUlfENbXSPK6VwmbPH55h966JQezNcj53+VkfJ1PR nTPeUoE35sPn4D
aH++L7ioPog0jLKovRUYX+KRvjjQdLPuQe0t5V+f81yo1cjr13 nL7o/ijfD6y/Me
9Vxr9kn/WwWQqlxzvb2UPtHYlFY+KbRnpGqh9bB4pP/y/dvEjcxjeNxxOGEHfIuP
tqVSBt0S6e326tsMXIQhPtYcd0j1KB+DCN0sV8QZpAlVbnq0Zs S2YbT9ls+RQdKr
9ttgwwZ6FLJungqul1QDIUh0qorBROTjC0J6bTrCoANyv0qYOM einPLB+dozZF4d
/9M1VM3mnn5b/YVbnmYR
=Mp6K
-----END PGP SIGNATURE-----
 
Old 01-18-2012, 07:01 PM
Mike Frysinger
 
Default 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
 
Old 01-18-2012, 07:02 PM
Mike Frysinger
 
Default 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
 
Old 01-18-2012, 07:45 PM
Rich Freeman
 
Default How help in arch testing work

On Wed, Jan 18, 2012 at 3:01 PM, Mike Frysinger <vapier@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
 
Old 01-18-2012, 09:26 PM
Agostino Sarubbo
 
Default 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 Sarubbo ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D
 

Thread Tools




All times are GMT. The time now is 12:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org