[gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[Arthur D.]

Hello, everyone.

I think all you know the utility revdep-rebuild. It's very usefull. But it  
has
some nasty features, such as totally ignoreing of emerge default options  
set in
/etc/make.conf

Would you like portage to be verbose? Ignored.
Do you like portage showing you what's going to be emerged? Ignored!
Do you wish portage to ask for your confirmation before actually doing  
compilation?
Yes, IGNORED!

Just press ctrl-c and enjoy scrolling. Then run again. No too user  
friendly.
You don't like that behaviour? Just add the desired options to command like
parameters. You don't like adding options explicitly? Hey, that's Gentoo,  
just make
a wrapper script and be happy ;-)

I wrote a letter Paul Varner, reporting him about that bug. And what did  
he answer?
That's a feature, not a bug. "We purposely do not honor  
EMERGE_DEFAULT_OPTS because not
to do so will break revdep-rebuild in unexpected ways"
Ok. There is easy, dumb and stupid way of fixing that - just filter out  
harmful options.

I suggested my help in developing the script. I asked him what options  
will break things...
No answer. 12 days left.

I made a report in bugzilla: http://bugs.gentoo.org/show_bug.cgi?id=289599
And was suggested to make the question up here.

Please, leave your comments, suggestions etc.
Thanks for attention.

-- 
Best regards, Spinal

[gentoo-portage-dev] Re: REVDEP-REBUILD and emerge default options

[Duncan]

Arthur D. posted on Tue, 20 Oct 2009 22:23:54 +0300 as excerpted:

> I suggested my help in developing the script. I asked him what options
> will break things...
> No answer. 12 days left.

FWIW, 12 days isn't so bad.  It's often two weeks before you get a first 
maintainer response on a bug (I'd call that normal, I don't even start to 
wonder until three have passed, yes, it IS hard to wait sometimes, when 
it's /your/ bug, but...), and I've had bugs with supplied patches sit for 
months before they get tested and implemented by the maintainer.  Since 
Gentoo is all volunteers, and "real life" can and does take precedence a 
lot of the time, this is simply a fact of life.  If someone doesn't like 
it, they can of course work to become a Gentoo dev and volunteer their 
own time to get things done faster, or perhaps if they have money, they 
can sponsor someone to work on it full time, or they can learn to live 
with it... or they can get tired of it and switch to one of the 
commercial distributions.

So I'm not going to get involved in the merits of the specific argument 
here, but thought I'd reply just to let you know to have a bit of 
patience.  12 days does NOT mean the maintainer is ignoring you, or that 
he won't actually agree with you when he does get to it.  Often, it just 
means he has "real life" (TM) to attend to, and perhaps a few more urgent 
bugs or bugs he was already in the middle of, and hasn't had time to give 
your mail the proper consideration it is due. =:^)

Actually, that he didn't answer right away might be an encouraging sign.  
He didn't reject the idea out of hand, and maybe he IS seriously 
considering it. I know I'd far rather have a reply delayed a couple weeks 
(or 3 or 4 or 6) and have some thoughtful consideration given to it, than 
have the thing rejected out of hand!  =:^)

That said, the bug was the way to go, as mail can get lost or eaten by 
the spam filter or whatever.  Gentoo uses the bug tracker for all sorts 
of stuff one wouldn't ordinarily think of as bugs, including tracking the 
progress of new devs and dev retirement when it's needed (on a private 
bug in some cases, of course).  Put it in a bug and it's in the system 
and will get proper consideration given it.  And if having filed it, you 
were told to bring it up here, that's good too.  =:^)

All I'm really saying is don't get too worried about a response time of a 
couple weeks or more.  That's simply a fact of life one deals with.

-- 
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

Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[Zac Medico]

Arthur D. wrote:
> Would you like portage to be verbose? Ignored.
> Do you like portage showing you what's going to be emerged? Ignored!
> Do you wish portage to ask for your confirmation before actually doing
> compilation?
> Yes, IGNORED!

I'd suggest passing the -p option to revdep-rebuild on the command
line. That's how I always do it. Then you can run it again and it's
supposed to cache the result (if you don't use the -i option).
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[Arthur D.]

To Duncan:
> FWIW, 12 days isn't so bad.
I didn't say 12 days is bad or something similar. I opened public bug  
report
after having no reply in 12 days. Did I something wrong?

To Zac:
> I'd suggest passing the -p option to revdep-rebuild on the command
> line. That's how I always do it. Then you can run it again and it's
> supposed to cache the result (if you don't use the -i option).
I know how to pass options on command line. I was asking about changing
default behaviour to respect emerge default options out-of-box. Passing
same options every time is not a good way of doing things, no?

-- 
Best regards, Spinal

[gentoo-portage-dev] Re: REVDEP-REBUILD and emerge default options

[Duncan]

Arthur D. posted on Wed, 21 Oct 2009 09:30:16 +0300 as excerpted:

> To Duncan:
>> FWIW, 12 days isn't so bad.
> I didn't say 12 days is bad or something similar. I opened public bug
> report after having no reply in 12 days. Did I something wrong?

I misunderstood you, then.  It read to me as if you had expected an 
answer in say two days, and thought he was slacking, so I replied based 
on that.  If that wasn't the case, no problem, continue as you were. =:^)

(Once in awhile we do get people who just expect things to move faster 
than they do, is all.  Once it's explained and expectations better match 
reality, users are happier because they don't think they're being 
ignored, and devs are happier because they don't feel like they're being 
pushed around by ungrateful users.  I thought this was one of those 
cases, but apparently thought wrong.)

-- 
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

Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[Zac Medico]

Arthur D. wrote:
> To Zac:
>> I'd suggest passing the -p option to revdep-rebuild on the command
>> line. That's how I always do it. Then you can run it again and it's
>> supposed to cache the result (if you don't use the -i option).
> I know how to pass options on command line. I was asking about changing
> default behaviour to respect emerge default options out-of-box. Passing
> same options every time is not a good way of doing things, no?

Yeah, I think your right. I suppose that revdep-rebuild could simply
assume that the default options are good and allow the user to
specify --ignore-default-opts if necessary. The only options that I
think would conflict are --update, --selective, and --noreplace.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[Douglas Anderson]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

There's probably not much reason why a filtered set of OPTS can't be
accepted. I haven't looked this over yet but this code should probably
handle the filtering:

http://overlays.gentoo.org/proj/python/changeset/171

from: https://bugs.gentoo.org/show_bug.cgi?id=282474#c4

-Doug

On Wed, Oct 21, 2009 at 6:03 PM, Zac Medico <zmedico@gentoo.org> wrote:

> Arthur D. wrote:
> > To Zac:
> >> I'd suggest passing the -p option to revdep-rebuild on the command
> >> line. That's how I always do it. Then you can run it again and it's
> >> supposed to cache the result (if you don't use the -i option).
> > I know how to pass options on command line. I was asking about changing
> > default behaviour to respect emerge default options out-of-box. Passing
> > same options every time is not a good way of doing things, no?
>
> Yeah, I think your right. I suppose that revdep-rebuild could simply
> assume that the default options are good and allow the user to
> specify --ignore-default-opts if necessary. The only options that I
> think would conflict are --update, --selective, and --noreplace.
> --
> Thanks,
> Zac
>
>

[-- Attachment #2: Type: text/html, Size: 1690 bytes --]

Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[Paul Varner]

On Tue, 2009-10-20 at 22:23 +0300, Arthur D. wrote:
> Hello, everyone.
>
> Just press ctrl-c and enjoy scrolling. Then run again. No too user  
> friendly.
> You don't like that behaviour? Just add the desired options to command like
> parameters. You don't like adding options explicitly? Hey, that's Gentoo,  
> just make
> a wrapper script and be happy ;-)
> 
> I wrote a letter Paul Varner, reporting him about that bug. And what did  
> he answer?
> That's a feature, not a bug. "We purposely do not honor  
> EMERGE_DEFAULT_OPTS because not
> to do so will break revdep-rebuild in unexpected ways"
> Ok. There is easy, dumb and stupid way of fixing that - just filter out  
> harmful options.
> 
> I suggested my help in developing the script. I asked him what options  
> will break things...
> No answer. 12 days left.

I apologize for the not responding.  I actually thought I had but
apparently did not.  Anyhow real life has me swamped right now, so I
can't give you an exact answer on what breaks and what doesn't break.
However, any option which can change the ordering of the packages can
break the rebuild of the packages and if it does will result in bugs
being filed against revdep-rebuild.

I am very much against allowing EMERGE_DEFAULT_OPTS in revdep-rebuild
since I went through hell trying to support it when it was first added
as a feature to portage and I really don't want to go through that
again.

Regards,
Paul

Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[Brian Harring]

On Mon, Oct 26, 2009 at 12:54:35PM -0500, Paul Varner wrote:
> I am very much against allowing EMERGE_DEFAULT_OPTS in revdep-rebuild
> since I went through hell trying to support it when it was first added
> as a feature to portage and I really don't want to go through that
> again.

Just out of curiousity, did you try a blacklist or a whitelist 
approach?

~brian

Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[Paul Varner]

On Mon, 2009-10-26 at 11:01 -0700, Brian Harring wrote:
> On Mon, Oct 26, 2009 at 12:54:35PM -0500, Paul Varner wrote:
> > I am very much against allowing EMERGE_DEFAULT_OPTS in revdep-rebuild
> > since I went through hell trying to support it when it was first added
> > as a feature to portage and I really don't want to go through that
> > again.
> 
> Just out of curiousity, did you try a blacklist or a whitelist 
> approach?

I tried a blacklist approach, however, it seemed like every time I
turned around some other option was causing it to break.  Finally, I got
fed up with the hassle and quit trying to support it.

Regards,
Paul

Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[Arthur D.]

> I am very much against allowing EMERGE_DEFAULT_OPTS in revdep-rebuild
> since I went through hell trying to support it when it was first added
> as a feature to portage and I really don't want to go through that
> again.

Paul, there's good option to filter _only_ safe options from  
EMERGE_DEFAULT_OPTS and
pass them to emerge. If you don't like to maintain it alone, I will help  
you.
Just forward all tickets connected to EMERGE_DEFAULT_OPTS to me. Deal?

-- 
Best regards, Spinal

Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[Paul Varner]

On Mon, 2009-10-26 at 20:04 +0200, Arthur D. wrote:
> > I am very much against allowing EMERGE_DEFAULT_OPTS in revdep-rebuild
> > since I went through hell trying to support it when it was first added
> > as a feature to portage and I really don't want to go through that
> > again.
> 
> Paul, there's good option to filter _only_ safe options from  
> EMERGE_DEFAULT_OPTS and
> pass them to emerge. If you don't like to maintain it alone, I will help  
> you.
> Just forward all tickets connected to EMERGE_DEFAULT_OPTS to me. Deal?

The biggest issue is determining that EMERGE_DEFAULT_OPTS is the
problem.  Anyhow, I'm looking at it to see what can be done.

Regards,
Paul