Mailing List Archive

On Tue, 2007-05-15 at 07:30 -0400, Caleb Tennis wrote:
> I'd like to open a bug soon requesting the stabiliztion of dev-libs/expat-2.0.0*.
> It's currently assigned to tcltk, but the bug traffic seems to indicate they don't
> know why they have it. If nobody steps up, objects, and is willing to take over
> maintenance I will do so.
>
> * - This version has a new soname, so it will require a revdep-rebuild, which is
> probably why it hasn't been stabilized as of now.

Yeah, exactly. I was too late to have things sorted out with people
maintaining (or the lack of it) to have this stabilized together with
GNOME-2.16, as the biggest desktop environments need to be
revdep-rebuilt to a large extent if not using --as-needed.

I hope you guys are going to do it together with a large KDE
stabilization spree then or something. I can time GNOME-2.16.3
stabilization to the same time as well, to minimize otherwise useless
revdep-rebuilding and include this with version updates.
Some pointer to use -X (--package-names) flag for revdep-rebuild
somewhere might be a good idea.


--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

On Tue, 15 May 2007 07:30:17 -0400 (EDT)
"Caleb Tennis" <caleb@gentoo.org> wrote:
> * - This version has a new soname, so it will require a
> revdep-rebuild, which is probably why it hasn't been stabilized as of
> now.

Isn't this why we have slots?

--
Ciaran McCreesh

> Isn't this why we have slots?

Yeah, but I think it's a hack in this case. All of the current versions in portage
are 1.95, which I believe were pre-releases to 2.0. As far as I can tell, nothing
is vastly different in 2.0 other than bug fixes and a final soname change. As well,
we'd have to put the slotted versions header files into directories where all of the
packages that depend on expat won't know where to find them.

It's going to cause a mess of "why did my program stop working?" bugs, but it's
probably one of these things that should have been done a long time ago.

--
gentoo-dev@gentoo.org mailing list

> Yeah, exactly. I was too late to have things sorted out with people
> maintaining (or the lack of it) to have this stabilized together with
> GNOME-2.16, as the biggest desktop environments need to be
> revdep-rebuilt to a large extent if not using --as-needed.
>
> I hope you guys are going to do it together with a large KDE
> stabilization spree then or something. I can time GNOME-2.16.3
> stabilization to the same time as well, to minimize otherwise useless
> revdep-rebuilding and include this with version updates.
> Some pointer to use -X (--package-names) flag for revdep-rebuild
> somewhere might be a good idea.

I'm certainly happy to time it with these big events. I think we're planning on a
KDE stabiliztion spree in a couple of weeks. I'll open a bug and CC interested
parties.

Caleb

--
gentoo-dev@gentoo.org mailing list

On Tue, 2007-05-15 at 07:47 -0400, Caleb Tennis wrote:
> > Yeah, exactly. I was too late to have things sorted out with people
> > maintaining (or the lack of it) to have this stabilized together with
> > GNOME-2.16, as the biggest desktop environments need to be
> > revdep-rebuilt to a large extent if not using --as-needed.
> >
> > I hope you guys are going to do it together with a large KDE
> > stabilization spree then or something. I can time GNOME-2.16.3
> > stabilization to the same time as well, to minimize otherwise useless
> > revdep-rebuilding and include this with version updates.
> > Some pointer to use -X (--package-names) flag for revdep-rebuild
> > somewhere might be a good idea.
>
> I'm certainly happy to time it with these big events. I think we're planning on a
> KDE stabiliztion spree in a couple of weeks. I'll open a bug and CC interested
> parties.

Ok, I can't wait with GNOME-2.16.3 that long. I'm already late a month.
I wonder how much packages KDE needs rebuilt with the expat bump
(revdep-rebuild --library expat.so or something like that). Maybe
including it in the GNOME bumps is a good idea if that has it for more
packages than KDE.

As for SLOTting, it was considered to be a maintenance nightmare by the
person who was maintaining expat before, and as Caleb already pointed
out in the correct subthread, not SLOTting seemed to be sensible course
of action in this case as I gathered too some months back when looking
into this while making stabilization lists for gnome 2.16.



--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

On Tuesday 15 May 2007, Ciaran McCreesh wrote:
> "Caleb Tennis" <caleb@gentoo.org> wrote:
> > * - This version has a new soname, so it will require a
> > revdep-rebuild, which is probably why it hasn't been stabilized as of
> > now.
>
> Isn't this why we have slots?

no
-mike

On Tuesday 15 May 2007, Caleb Tennis wrote:
> * - This version has a new soname, so it will require a revdep-rebuild,
> which is probably why it hasn't been stabilized as of now.

so add a call to preserve_old_lib / preserve_old_lib_notify like should have
been in there in the first place ... see latest readline ebuild for an
example
-mike

On Tue, 15 May 2007 08:22:47 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 15 May 2007, Caleb Tennis wrote:
> > * - This version has a new soname, so it will require a
> > revdep-rebuild, which is probably why it hasn't been stabilized as
> > of now.
>
> so add a call to preserve_old_lib / preserve_old_lib_notify like
> should have been in there in the first place ... see latest readline
> ebuild for an example

preserve_old_lib is a horrible hack that shouldn't be being used at all.
Don't push it as an alternative for proper slotting.

--
Ciaran McCreesh

Mike Frysinger napsal(a):
> On Tuesday 15 May 2007, Caleb Tennis wrote:
>> * - This version has a new soname, so it will require a revdep-rebuild,
>> which is probably why it hasn't been stabilized as of now.
>
> so add a call to preserve_old_lib / preserve_old_lib_notify like should have
> been in there in the first place ... see latest readline ebuild for an
> example
> -mike

If you read the bug with loads of duplicates; it's been avoided as well,
because it was considered unsafe for the same reason as slotting.

<flamebait>
The amount of crap that needs to be recompiled is much lower on systems
w/ --as-needed :P
</flamebait>


--
Best regards,

Jakub Moc
mailto:jakub@gentoo.org
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E

... still no signature ;)

On Tuesday 15 May 2007, Ciaran McCreesh wrote:
> Mike Frysinger <vapier@gentoo.org> wrote:
> > On Tuesday 15 May 2007, Caleb Tennis wrote:
> > > * - This version has a new soname, so it will require a
> > > revdep-rebuild, which is probably why it hasn't been stabilized as
> > > of now.
> >
> > so add a call to preserve_old_lib / preserve_old_lib_notify like
> > should have been in there in the first place ... see latest readline
> > ebuild for an example
>
> preserve_old_lib is a horrible hack that shouldn't be being used at all.
> Don't push it as an alternative for proper slotting.

funny, i could say the same thing for your "proper slotting"

SLOTing is for API changes, not ABI changes

ABI tracking is the realm of the package manager and until portage has this
integrated, the preserve_old_lib hack is the current solution
-mike

On Tue, 15 May 2007 08:52:32 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> > preserve_old_lib is a horrible hack that shouldn't be being used at
> > all. Don't push it as an alternative for proper slotting.
>
> funny, i could say the same thing for your "proper slotting"
>
> SLOTing is for API changes, not ABI changes

SLOTs are for where a user may want to have multiple versions of the
same package installed, for example where they require headers from two
different versions or where they require shared objects from two
different versions.

--
Ciaran McCreesh

> If you read the bug with loads of duplicates; it's been avoided as well,
> because it was considered unsafe for the same reason as slotting.

I just read the bug, but I don't see any compelling reason against using the
preserve_old stuff. It seems like it's a good balance that will mitigate the issue
for the majority of users until they can purge their systems of the old expat.

Caleb

--
gentoo-dev@gentoo.org mailing list

> Ok, I can't wait with GNOME-2.16.3 that long. I'm already late a month.
> I wonder how much packages KDE needs rebuilt with the expat bump
> (revdep-rebuild --library expat.so or something like that). Maybe
> including it in the GNOME bumps is a good idea if that has it for more
> packages than KDE.

From my point of view, you're certainly welcome to do this sooner if you would like.
I just wanted to get the ball rolling.

I think the preserve_old_libs thing might just be the hack we need here.

Caleb

--
gentoo-dev@gentoo.org mailing list

On Tuesday 15 May 2007, Jakub Moc wrote:
> Mike Frysinger napsal(a):
> > On Tuesday 15 May 2007, Caleb Tennis wrote:
> >> * - This version has a new soname, so it will require a revdep-rebuild,
> >> which is probably why it hasn't been stabilized as of now.
> >
> > so add a call to preserve_old_lib / preserve_old_lib_notify like should
> > have been in there in the first place ... see latest readline ebuild for
> > an example
>
> If you read the bug with loads of duplicates;

i'm assuming you mean 128069 since you failed to mention what bug you're
actually referring to

> it's been avoided as well,
> because it was considered unsafe for the same reason as slotting.

ha, i doubt it ... the code snippet i referred to in readline is not even
close to being the same thing as SLOTTing

if you're referring to the comment you made (which you should have just posted
in the e-mail instead of telling people to go find some random bug):
Because it's not safe here, stuff can continue to link against the old
libexpat ABI. Again, read the backlog before posting yet another comment
here.

revdep-rebuild will rebuild applications in the proper order which makes this
comment irrelevant
-mike

Ciaran McCreesh kirjoitti:
> On Tue, 15 May 2007 08:52:32 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
>>> preserve_old_lib is a horrible hack that shouldn't be being used at
>>> all. Don't push it as an alternative for proper slotting.
>> funny, i could say the same thing for your "proper slotting"
>>
>> SLOTing is for API changes, not ABI changes
>
> SLOTs are for where a user may want to have multiple versions of the
> same package installed, for example where they require headers from two
> different versions or where they require shared objects from two
> different versions.
>

And then you suggest we have support code to make the headers not
collide? I think time would be better spent improving the package
manager[s] instead of hacks like this.

Regards,
Petteri

On Tue, 15 May 2007 17:02:05 +0300
Petteri Räty <betelgeuse@gentoo.org> wrote:
> > SLOTs are for where a user may want to have multiple versions of the
> > same package installed, for example where they require headers from
> > two different versions or where they require shared objects from two
> > different versions.
>
> And then you suggest we have support code to make the headers not
> collide? I think time would be better spent improving the package
> manager[s] instead of hacks like this.

It is not, in general, a package manager solvable solution. In the real
world many packages have runtime dependencies that are not .so files.

--
Ciaran McCreesh

On Dienstag, 15. Mai 2007, Caleb Tennis wrote:
> I just read the bug, but I don't see any compelling reason against using
> the preserve_old stuff.

The big problem with it is that we do not store information about retained
libraries and let portage throw warnings. When people miss such a post
install message, the library potentially remains forever in the system, not
unlikely with seldom updated stuff linking against it. As soon as a
vulnerability is popping up, the system is vulnerable, remains vulnerable and
its owner assumes everything is fine.


Carsten

> I think the preserve_old_libs thing might just be the hack we need here.

It's been brought to my attention that a bad side effect from using the
preserve_old_libs method is that if an intermediary library, like qt3, gets rebuilt
then you end up having both expat libraries linked against the kde libraries at the
same time which causes rather undesriable crashes. Presumably this will affect
GNOME in a similar fashion as well.

In summary: there's no good way to do this, and someone is going to have to pick.
No matter what, the choice will come with critism. I'm volunteering to take the
heat, unless someone beats me to the punch.

Caleb

--
gentoo-dev@gentoo.org mailing list

On Dienstag, 15. Mai 2007, Ciaran McCreesh wrote:
> preserve_old_lib is a horrible hack that shouldn't be being used at all.
> Don't push it as an alternative for proper slotting.

In it's current state it's indeed a horrible hack. But slotting is in many
cases no solution either. When you have to move headers and other files to
avoid file collisions and have to adjust every single dependending package
accordingly, it's quickly getting a ridiculous maintenance nightmare.


Carsten

Caleb Tennis napsal(a):
>> I think the preserve_old_libs thing might just be the hack we need here.
>
> It's been brought to my attention that a bad side effect from using the
> preserve_old_libs method is that if an intermediary library, like qt3, gets rebuilt
> then you end up having both expat libraries linked against the kde libraries at the
> same time which causes rather undesriable crashes. Presumably this will affect
> GNOME in a similar fashion as well.

Exactly one of the reasons there's been no preserve_old_libs thing in
the ebuild in the first place.

It's been discussed with the original maintainer over and over again,
and the conclusion was that it's not safe to have two versions of expat
installed on the same system. So, why don't we just stick to that and be
done with it?


--
Best regards,

Jakub Moc
mailto:jakub@gentoo.org
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E

... still no signature ;)

On Dienstag, 15. Mai 2007, Mart Raudsepp wrote:
> Ok, I can't wait with GNOME-2.16.3 that long. I'm already late a month.
> I wonder how much packages KDE needs rebuilt with the expat bump
> (revdep-rebuild --library expat.so or something like that). Maybe
> including it in the GNOME bumps is a good idea if that has it for more
> packages than KDE.

If we want to take this to measure, it' a bigger problem for KDE users (unless
built with --as-needed). The list of packages is unfortunately
quite "impressive". What was your plan wrt. stabilisation of Gnome? I can
look at the remaining issues this evening, so maybe we can speed up the
process a bit. The bigger problem I see on the side of the arch teams. I got
used to (nah, not really) mips and alpha lagging behind for several months,
but the amd64 team is unresponsive on even trivial stabilisation request form
the KDE team as well, lately.


Carsten

Carsten Lohrke <carlo@gentoo.org>:

> but the amd64 team is unresponsive on even trivial stabilisation
> request form the KDE team as well, lately.

You will get them tomorrow...promised. :) Too many bugs, not enough
devs...as always.

--
http://www.gentoo.org/
http://www.faulhammer.org/
http://www.gnupg.org/

> It's been discussed with the original maintainer over and over again,
> and the conclusion was that it's not safe to have two versions of expat
> installed on the same system. So, why don't we just stick to that and be
> done with it?

Yep, I'm on that page as well. I will push the stabilization when the time is right
with either Gnome or KDE, whomever pushes harder and comes first.

--
gentoo-dev@gentoo.org mailing list

"Caleb Tennis" <caleb@gentoo.org> posted
38928.192.168.2.155.1179228617.squirrel@www.aei-tech.com, excerpted below,
on Tue, 15 May 2007 07:30:17 -0400:

> I'd like to open a bug soon requesting the stabiliztion of
> dev-libs/expat-2.0.0*. It's currently assigned to tcltk, but the bug
> traffic seems to indicate they don't know why they have it. If nobody
> steps up, objects, and is willing to take over maintenance I will do so.
>
> * - This version has a new soname, so it will require a revdep-rebuild,
> which is probably why it hasn't been stabilized as of now.

I don't see it mentioned in the bug (128069 anyway) or in the discussion
so far, and while it might be considered obvious, just in case...

Wasn't the ~ intro of this what precipitated the whole GLEP 42 (news)
thing? I know news came up again recently and due to the lack of a news
reading client for portage, further use was put on hold. Has that been
resolved? Because if there's a place where a preemptive news function is
needed, this is it! Thus, if at all possible, having news working and
using it for this should be SERIOUSLY considered.

Regardless of whether news is ready or not, however, please make sure
it's covered in GWN at LEAST the week prior, and preferably for a couple
weeks in a row. (Yes, an upgrade /can/ be that bad.) Also, please make
sure it's announced on the forums and on the user list. For those that
don't see it after that, well... at least there'll be plenty of places to
refer the bug filers to.

Alternatively, this is the /one/ case I've come across where I might
actually be in favor of putting an IM_SURE_IM_READY_TO_UPGRADE_EXPAT=1
test in the ebuild, dying if not. (No, I didn't /think/ that'd go
anywhere, but seriously, if there's a case where it might be warranted,
this is it. Not saying that it is.)

It's probably a bit late now (unless we want to wait yet another few
months), but tying this to a profile upgrade might have been a more
practical solution. 2007.0, or now 2007.1. Old profiles would stick
with the old expat, and new ones would get the new one. People are
generally prepared for at least a /bit/ of extra upheaval when they do
profile upgrades, and that would have made the PR a bit easier as well,
since that's a natural time for it.

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

--
gentoo-dev@gentoo.org mailing list