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

 
 
LinkBack Thread Tools
 
Old 02-03-2009, 02:36 PM
Neil Bothwick
 
Default libtool problem

On Tue, 3 Feb 2009 20:23:17 +0500, Mike Kazantsev wrote:

> And I hate to re-emerge same gcc every time some minor bug (which I
> didn't happen to reproduce) is fixed.

IKWYM but I think, on balance, this one would have benefited from a bump
as the effects of the breakage were quite widespread. It did make a
difference to the installed files, which is the usual criterion for a
bump.


--
Neil Bothwick

THE BORG: Calm, Cool and Collective...
 
Old 02-04-2009, 02:25 AM
ABCD
 
Default libtool problem

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Bothwick wrote:
> Mike Kazantsev wrote:
>
>> And I hate to re-emerge same gcc every time some minor bug (which I
>> didn't happen to reproduce) is fixed.
>
> IKWYM but I think, on balance, this one would have benefited from a bump
> as the effects of the breakage were quite widespread. It did make a
> difference to the installed files, which is the usual criterion for a
> bump.

The reason there wasn't a bump (IIRC) was that the ebuild never changed
- - only the eclass did. If you emerged any version of GCC during the
window where the eclass was broken, that version of GCC would have been
broken.

- --
ABCD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmJCq4ACgkQOypDUo0oQOqeqwCgrFG9t4t3+Z mTKY5EcjW81Ab/
YIoAmQEQh7FXNlrIj/dCmqSGoIk+g4YG
=3Eiv
-----END PGP SIGNATURE-----
 
Old 02-04-2009, 08:50 AM
Neil Bothwick
 
Default libtool problem

On Tue, 03 Feb 2009 22:25:34 -0500, ABCD wrote:

> The reason there wasn't a bump (IIRC) was that the ebuild never changed
> - - only the eclass did. If you emerged any version of GCC during the
> window where the eclass was broken, that version of GCC would have been
> broken.

Of course, I'd forgotten that the change was in the eclass.


--
Neil Bothwick

I understand the answers, the questions throw me.
 
Old 02-04-2009, 05:17 PM
Dirk Heinrichs
 
Default libtool problem

Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD:

> The reason there wasn't a bump (IIRC) was that the ebuild never changed
> - only the eclass did. *If you emerged any version of GCC during the
> window where the eclass was broken, that version of GCC would have been
> broken.

That also means that portage is broken. Whenever something changes where other
things depend on, those other things should be rebuilt. This doesn't happen
here.

Bye...

Dirk
 
Old 02-04-2009, 07:21 PM
Alan McKinnon
 
Default libtool problem

On Wednesday 04 February 2009 20:17:33 Dirk Heinrichs wrote:
> Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD:
> > The reason there wasn't a bump (IIRC) was that the ebuild never changed
> > - only the eclass did. *If you emerged any version of GCC during the
> > window where the eclass was broken, that version of GCC would have been
> > broken.
>
> That also means that portage is broken. Whenever something changes where
> other things depend on, those other things should be rebuilt. This doesn't
> happen here.

I disagree, that would cause many more spurious rebuilds than is needed if it
were automated. Portage cannot tell how important or how deep a change is,
that requires a human to look and see. So what is needed is a flag that
portage recognizes as an instruction to do a revdep-rebuild-style search and
find everything using a specific changed file, and rebuild those. The flag is
set under dev control.

Blindly doing what you suggest leads to this:

appA depends on libB.
libB has a bug which is fixed but no changes to the API or ABI occur, so appA
does not need to be rebuilt, it simply uses the new compiled lib when run.
This circumstance will likely happen many many times more often that the
updated eclass that is the subject of this thread.

Therefore, a simple elog entry is a valid handling and fully compliant with
the principle of The Simplest Thing That Could Possibly Work.

--
alan dot mckinnon at gmail dot com
 
Old 02-04-2009, 07:40 PM
Dirk Heinrichs
 
Default libtool problem

Am Mittwoch, 4. Februar 2009 21:21:38 schrieb Alan McKinnon:
> On Wednesday 04 February 2009 20:17:33 Dirk Heinrichs wrote:
> > Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD:
> > > The reason there wasn't a bump (IIRC) was that the ebuild never changed
> > > - only the eclass did. *If you emerged any version of GCC during the
> > > window where the eclass was broken, that version of GCC would have been
> > > broken.
> >
> > That also means that portage is broken. Whenever something changes where
> > other things depend on, those other things should be rebuilt. This
> > doesn't happen here.
>
> I disagree, that would cause many more spurious rebuilds than is needed if
> it were automated.

Why spurious? The package manager should be smart enough to tell the user:
"Rebuild because of eclass change". Nothing spurious.

> Portage cannot tell how important or how deep a change
> is, that requires a human to look and see. So what is needed is a flag that
> portage recognizes as an instruction to do a revdep-rebuild-style search
> and find everything using a specific changed file, and rebuild those. The
> flag is set under dev control.

Not dev, user. Something equivalent to --newuse.

> Blindly doing what you suggest leads to this:
>
> appA depends on libB.

No. Sorry if this was misleading. I was only referring to dependencies between
ebuilds and eclasses.

Library interdependencies are handled just fine by portage/revdep-rebuild.

> Therefore, a simple elog entry is a valid handling and fully compliant with
> the principle of The Simplest Thing That Could Possibly Work.

Elog entries are overlooked too often.

Bye...

Dirk
 
Old 02-04-2009, 08:07 PM
Alan McKinnon
 
Default libtool problem

On Wednesday 04 February 2009 22:40:26 Dirk Heinrichs wrote:
> Am Mittwoch, 4. Februar 2009 21:21:38 schrieb Alan McKinnon:
> > On Wednesday 04 February 2009 20:17:33 Dirk Heinrichs wrote:
> > > Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD:
> > > > The reason there wasn't a bump (IIRC) was that the ebuild never
> > > > changed - only the eclass did. *If you emerged any version of GCC
> > > > during the window where the eclass was broken, that version of GCC
> > > > would have been broken.
> > >
> > > That also means that portage is broken. Whenever something changes
> > > where other things depend on, those other things should be rebuilt.
> > > This doesn't happen here.
> >
> > I disagree, that would cause many more spurious rebuilds than is needed
> > if it were automated.
>
> Why spurious? The package manager should be smart enough to tell the user:
> "Rebuild because of eclass change". Nothing spurious.

Portage only knows that the eclass changed. It does not know what the result
of that change will be. Therefore it is not in a position to mandate that a
rebuild of other apps is *required* in order to function correctly. Which
leaves us with two options:

Tell the user to look and decide for themselves, or
Rebuild everything using the eclass anyway

The latter option will always fix problems but at a huge cost of most often
rebuilding something that looks like it needs rebuilding but actually
doesn't. Therefore spurious.

> > Portage cannot tell how important or how deep a change
> > is, that requires a human to look and see. So what is needed is a flag
> > that portage recognizes as an instruction to do a revdep-rebuild-style
> > search and find everything using a specific changed file, and rebuild
> > those. The flag is set under dev control.
>
> Not dev, user. Something equivalent to --newuse.

I was thinking more along the lines of what @preserved-rebuild does. Some
mechanism in the ebuild that includes a package in a list of stuff to be
rebuilt. Obviously this is something new and a fairly deep change to portage
so I can't think of a decent parallel or analogy.

> > Blindly doing what you suggest leads to this:
> >
> > appA depends on libB.
>
> No. Sorry if this was misleading. I was only referring to dependencies
> between ebuilds and eclasses.

OK

> Library interdependencies are handled just fine by portage/revdep-rebuild.
>
> > Therefore, a simple elog entry is a valid handling and fully compliant
> > with the principle of The Simplest Thing That Could Possibly Work.
>
> Elog entries are overlooked too often.

True, but do we have anything better? As in a proven mechanism successfully
used elsewhere to deal with comparable situations?



--
alan dot mckinnon at gmail dot com
 

Thread Tools




All times are GMT. The time now is 11:39 AM.

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