Re: [gentoo-dev] RFC about another *DEPEND variable

[Mike Frysinger]

On Saturday 30 September 2006 15:34, Brian Harring wrote:
> If that's what folks want, sure, but what you're proposing is just
> sliding NEEDED in as the defacto solution without labeling it as such.

no idea what this means

> Re-read your emails, and mine please.  The scenario I pointed out was
> ctrl+c'ing the merge while it's doing a rebuild for lib1 to lib2.

then let me turn it around ... how exactly does your solution account for all 
these little details ?  i dont recall you outlining anything ...

> > > How exactly is this forcing wasted rebuilds?  You're stating that
> > > maintainers are going to bump it willy nilly.  As I said, it is a key
> > > that would be bumped *as needed*, and would only affected pkgs that
> > > specified that node as a binding dep (specially marked atom).
> >
> > no, i mean for example scenarios where a package provides more than one
> > library (say libfoo and libbar) and only one of those changes ABI values
> > (say libfoo.0 -> libfoo.1).  if another package links against just
> > libbar, you've got a pointless rebuild.
>
> If one changes it's version, it's a fair bet that any consumer of that
> pkg is linked to more then just that lib; as such they would be
> rebuilt *anyways*.

it isnt guaranteed ... you asked for a pointless rebuild and i gave you 
one ... one that is not falsely flagged when reviewing the NEEDED list

the other example is where the ABI changes for one arch but not for any 
other ... what do you do, force ABI rebuild for everyone ?  ok, maybe that 
arch was x86 so we say screw you to the smaller arch teams ... but what if 
that arch was a smaller arch team ?

> Sorry, but if a developer is bumping a pkg and doesn't even look to
> see if the damn thing is potentially going to break others via soname
> changes, that maintainer is being an idiot.

and yet it does happen and again, we're looking at this from different 
angles ... you'd rather assume the developer is 100% competent and never gets 
things wrong; i'd rather assume nothing and let the details be discovered 
automatically.

in the end, the people using Gentoo are the ones that suffer and i'm tired of 
seeing systems broken beyond usuability because a developer unleashed a 
package without realizing the consequences of it

> > > Realistically, just the same as the NEEDED solution has holes, the
> > > maintaining dev can screw up and miss a BINCOMPAT bump.  Difference is
> > > that they can do something for BINCOMPAT; hell, QA checks can be
> > > automated to catch missing BINCOMPAT bumps.

i bet a post-emerge would make this painless and automate the QA step ... 
after src_install(), you run something like `scanelf -qsRS ${D}` and save the 
results in vdb/SONAME ... and then on subsequent installs, you run it again 
and if the SONAME changes but BINCOMPAT did not, you bail with a die message 
telling the user to go file a bug and preventing the merge which would have 
broken his system

> > > KEYWORDed arches bit, bit unlikely that the underlying arch is
> > > actually going to screw with the soname, thus I'd want actual examples
> > > backing it up.
> >
> > how about libc.so from glibc and libgcc.so from gcc ?  or would you like
> > other packages ?
>
> Considering such a change would be internal ABI, NEEDED doesn't
> actually fix anything; if it were a soname change, level playing
> ground again.

it is a SONAME change, why else would i mention this

> Reiterating; devs should know the high level affects of their changes.

reiterating: you're hoping for the best; i'm looking at our history and 
assuming that devs will make mistakes as everyone does

> If it's going to change the soname version, they should know from the
> get go- unless it's an arch specific breakage (which I still posit is
> the rare/corner case), they will *see* it for their arch and bump it
> already.

maybe, but it's still a possibility which analyzing of SONAME would catch

> Stating that things are broken doesn't make NEEDED automagically
> better either; *both* enable a way to fix it, so you need to justify
> the "accounting for the worst; not hoping for the best".

justify how ?  would you like me to dig up the bugs where devs bumped packages 
into stable and the SONAME change broke a ton of people's systems ?  has it 
never happened to you ?

> > > > or dig
> > > > through the source code line by line and hope to catch all such cases
> > > > by hand/eye ?
> > >
> > > Bit of FUD here, although I spose I'll just point out that if so's
> > > change as massively as you're implying above, the affects on -p are
> > > that much worse.
> >
> > awesome, mark something you disagree with as FUD, problem solved.  my
> > point is that you can never know completely for sure the behavior of a
> > package without digging through the entire source code.
>
> It's FUD due to the fact NEEDED suffers the same fucking issue.  The
> irony is that BINCOMPAT would at least give a knob to mark it as a
> breakage, NEEDED cannot.

and then you get angry ?  try to have a discussion without getting all anxious 
as that only wastes time

there's a few issues here, not just one ...
 - ABI change w/no SONAME bump - impossible to catch without reading source; 
BINCOMPAT would allow for it; NEEDED would not
 - ABI change w/SONAME bump - BINCOMPAT would not catch; NEEDED would

> Frankly, if you don't believe me or think my points are correct about
> how a NEEDED based solution is going to suck, zac/jason/genone/anyone
> else.  They're going to point out the same flaws.

if you dont want to hash out ideas on a development list but rather just 
declare one right and one wrong, then feel free to leave.  if you're confused 
about my intentions here then let me set you straight.  i see advantages to 
both sides and i'm going to argue out problems until we have something good 
to push back into portage.  i dont really care if the final solution is "my 
idea" or not; such personal ties is just stupid and helps no one.
-mike