[gentoo-dev] stabilizing expat 2.0.0

[gentoo-dev] stabilizing expat 2.0.0

[Caleb Tennis]

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.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] stabilizing expat 2.0.0

[Mart Raudsepp]

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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Caleb Tennis]

> 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

Re: [gentoo-dev] stabilizing expat 2.0.0

[Mart Raudsepp]

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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Caleb Tennis]

> 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

Re: [gentoo-dev] stabilizing expat 2.0.0

[Caleb Tennis]

> 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

Re: [gentoo-dev] stabilizing expat 2.0.0

[Jakub Moc]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Caleb Tennis]

> 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

Re: [gentoo-dev] stabilizing expat 2.0.0

[Carsten Lohrke]

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

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: stabilizing expat 2.0.0

[Christian Faulhammer]

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

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/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Wulf C. Krueger]

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

On Tuesday, May 15, 2007 05:29:44 PM Christian Faulhammer wrote:
> 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.

Well, I've offered my help with the amd64 team three times now. Was 
ignored two times and the third time an initial discussion lead to 
nowhere so I guess it's not exactly of getting more devs but wanting 
them - or not.

Best regards, Wulf

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: stabilizing expat 2.0.0

[Christian Faulhammer]

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

"Wulf C. Krueger" <philantrop@gentoo.org>:

> >  You will get them tomorrow...promised. :)  Too many bugs, not
> > enough devs...as always.
> Well, I've offered my help with the amd64 team three times now. Was 
> ignored two times and the third time an initial discussion lead to 
> nowhere so I guess it's not exactly of getting more devs but wanting 
> them - or not.

 Hmmm, I don't know how you did it, but I just nagged some people for
a day and was in it...and that was just a few weeks ago.

V-Li 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Raúl Porcel]

Christian Faulhammer wrote:
> "Wulf C. Krueger" <philantrop@gentoo.org>:
> 
>>>  You will get them tomorrow...promised. :)  Too many bugs, not
>>> enough devs...as always.
>> Well, I've offered my help with the amd64 team three times now. Was 
>> ignored two times and the third time an initial discussion lead to 
>> nowhere so I guess it's not exactly of getting more devs but wanting 
>> them - or not.
> 
>  Hmmm, I don't know how you did it, but I just nagged some people for
> a day and was in it...and that was just a few weeks ago.
> 
> V-Li 
> 

That's because they want you to do the java bugs *g*
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] stabilizing expat 2.0.0

[Raúl Porcel]

Carsten Lohrke wrote:
> 
> 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

I'm doing all the bugs for alpha right now. I'm working on all the kde
bugs, and kdepim is so sloooooooooow compiling.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] stabilizing expat 2.0.0

[Carsten Lohrke]

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

Christian, Raúl - you guys rock!


Carsten

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: stabilizing expat 2.0.0

[Steve Long]

Carsten Lohrke wrote:
> the amd64 team is unresponsive on even trivial stabilisation
> request form the KDE team as well, lately.
>
welp's been away ;)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Jakub Moc]

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

Steve Long napsal(a):
> welp's been away ;)

Oh well, the dreaded *buntu maintenance eats time, you know... *g*


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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: stabilizing expat 2.0.0

[Christian Faulhammer]

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

Steve Long <slong@rathaus.eclipse.co.uk>:

> Carsten Lohrke wrote:
> > the amd64 team is unresponsive on even trivial stabilisation
> > request form the KDE team as well, lately.
> >
> welp's been away ;)

 welp does not touch KDE packages...

V-Li

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Daniel Gryniewicz]

On Fri, 2007-05-18 at 23:33 +0200, Christian Faulhammer wrote:
> Steve Long <slong@rathaus.eclipse.co.uk>:
> 
> > Carsten Lohrke wrote:
> > > the amd64 team is unresponsive on even trivial stabilisation
> > > request form the KDE team as well, lately.
> > >
> > welp's been away ;)
> 
>  welp does not touch KDE packages...
> 

More importantly, I don't think anyone currently active on amd64 does
touch KDE packages.   Looking at changelogs, kugelfang is active (but
not stabling amd64, it seems); wolf31o2 and cryos are away; lanius,
absinthe, and jhuebel are no longer on amd64; that leaves malc, who
hasn't done anything kde related since 2004, as far as I can see.

I suspect the kde team and the amd64 team need to get together to find
someone who can test KDE on amd64.

Daniel

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] stabilizing expat 2.0.0

[Ciaran McCreesh]

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

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Caleb Tennis]

> 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

Re: [gentoo-dev] stabilizing expat 2.0.0

[Mike Frysinger]

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

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Mike Frysinger]

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

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Ciaran McCreesh]

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

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Mike Frysinger]

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

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Ciaran McCreesh]

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

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Petteri Räty]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Ciaran McCreesh]

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

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Carsten Lohrke]

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

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] stabilizing expat 2.0.0

[Caleb Tennis]

> 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

Re: [gentoo-dev] stabilizing expat 2.0.0

[Carsten Lohrke]

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

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: stabilizing expat 2.0.0

[Mike Frysinger]

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

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

[gentoo-dev] Re: stabilizing expat 2.0.0

[Duncan]

"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

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Rémi Cardona]

Duncan wrote:
> 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.

Sounds good to me. To complement what Mart (leio) said earlier, a good
timing for Gnome is either 2.16.3 or 2.18.0/1, the latter not being due
for stable in for another few weeks.

My opinion: the sooner the better. But having new stages for new
installs so that users don't have to find out about revdep-rebuild the
minute they finish their install is probably the best way to go.

The profile idea looks ideal.

Rémi

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: stabilizing expat 2.0.0

[Markus Ullmann]

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

Rémi Cardona schrieb:
> The profile idea looks ideal.

Yup, +1 on that one

-Jokey


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Chris Gianelloni]

On Tue, 2007-05-15 at 20:08 +0200, Rémi Cardona wrote:
> Duncan wrote:
> > 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.
> 
> Sounds good to me. To complement what Mart (leio) said earlier, a good
> timing for Gnome is either 2.16.3 or 2.18.0/1, the latter not being due
> for stable in for another few weeks.
> 
> My opinion: the sooner the better. But having new stages for new
> installs so that users don't have to find out about revdep-rebuild the
> minute they finish their install is probably the best way to go.
> 
> The profile idea looks ideal.

No.  It would have been ideal if we would have done it with the release.
Now, it means people *will* need to use revdep-rebuild as soon as they
install their shiny new system if they use binary packages.  People
coming from stage3 would be fine, of course.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Petteri Räty]

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



Chris Gianelloni kirjoitti:
> 
> No.  It would have been ideal if we would have done it with the release.
> Now, it means people *will* need to use revdep-rebuild as soon as they
> install their shiny new system if they use binary packages.  People
> coming from stage3 would be fine, of course.
> 

stage3 has expat too so they need to revdep-rebuild too

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Caleb Tennis]

>> No.  It would have been ideal if we would have done it with the release.
>> Now, it means people *will* need to use revdep-rebuild as soon as they
>> install their shiny new system if they use binary packages.  People
>> coming from stage3 would be fine, of course.
>>
>

I would have been happy to do that, but honestly Chris, the thought of approaching
you and asking you to bump something like that into 2007.0 scared the crap out of
me.  You seemed way overburdened for the release as it was.

I have no problem waiting for 2007.1, if Gnome and KDE don't mind.  I don't know
what hackery has to take place to do that, but I'm sure someone out there does.

Caleb


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: stabilizing expat 2.0.0

[Duncan]

"Caleb Tennis" <caleb@gentoo.org> posted
35060.192.168.2.155.1179337715.squirrel@www.aei-tech.com, excerpted below,
on  Wed, 16 May 2007 13:48:35 -0400:

> I have no problem waiting for 2007.1, if Gnome and KDE don't mind.  I
> don't know what hackery has to take place to do that, but I'm sure
> someone out there does.

What sort of timing are we looking at for 2007.1 anyway?  With .0 delayed 
as it was, is .1 going to be relatively quick, say August, or are we 
looking at November now?

If it's August, there shouldn't be much KDE to upgrade, maybe stabilize 
3.5.6.  4.0 is the big one, but that's tentatively timed for Sept. if I'm 
not mistaken, and if release dates don't slip.  If 2007.1 is November, 
there's a slim chance of getting 4.0 in, but not if it's like 3.5 was 
(IIRC 3.5.0 and 3.5.1 never stabilized, it was 3.5.2 before the issues 
were worked out enough to stabilize, which would put bump stable KDE 
4.0.x to 2008.0 at the earliest).

I doubt anyone wants to wait for a a November expat-2 stabilization, 
however, so if 2007.1's going to be that long, unless we want to talk 
about 2007.0-r1 and I doubt anyone's up for that either, the timing just 
doesn't look like it's going to work for a release/profile timed expat-2 
stabilization.  It'd be nice, but...

So what /does/ the timing look like for 2007.1?

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

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Rumen Yotov]

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

Duncan написа:
> "Caleb Tennis" <caleb@gentoo.org> posted
> 35060.192.168.2.155.1179337715.squirrel@www.aei-tech.com, excerpted below,
> on  Wed, 16 May 2007 13:48:35 -0400:
> 
>> I have no problem waiting for 2007.1, if Gnome and KDE don't mind.  I
>> don't know what hackery has to take place to do that, but I'm sure
>> someone out there does.
> 
> What sort of timing are we looking at for 2007.1 anyway?  With .0 delayed 
> as it was, is .1 going to be relatively quick, say August, or are we 
> looking at November now?
> 
> If it's August, there shouldn't be much KDE to upgrade, maybe stabilize 
> 3.5.6.  4.0 is the big one, but that's tentatively timed for Sept. if I'm 
> not mistaken, and if release dates don't slip.  If 2007.1 is November, 
> there's a slim chance of getting 4.0 in, but not if it's like 3.5 was 
> (IIRC 3.5.0 and 3.5.1 never stabilized, it was 3.5.2 before the issues 
> were worked out enough to stabilize, which would put bump stable KDE 
> 4.0.x to 2008.0 at the earliest).
> 
> I doubt anyone wants to wait for a a November expat-2 stabilization, 
> however, so if 2007.1's going to be that long, unless we want to talk 
> about 2007.0-r1 and I doubt anyone's up for that either, the timing just 
> doesn't look like it's going to work for a release/profile timed expat-2 
> stabilization.  It'd be nice, but...
> 
> So what /does/ the timing look like for 2007.1?
> 
Hi,
Might i sugest making an doc "expat-upgrade" and posting it in Docs (or 
some dev's space).
This only for those who can't wait and want earlier upgrade.
Even can participate in making it, if needed.
Rumen


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3493 bytes --]

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Rémi Cardona]

Rumen Yotov wrote:
> Hi,
> Might i sugest making an doc "expat-upgrade" and posting it in Docs (or
> some dev's space).
> This only for those who can't wait and want earlier upgrade.
> Even can participate in making it, if needed.

Three easy steps:
1) unmask it
2) revdep-rebuild
3) profit !

Really, out of all the build issues one could have with changing .so
names, expat is the easiest I've had to handle. It doesn't break any low
level portage utils like openssl did.

It's just _very_ long since you'd have to rebuild 90% of your packages
on an average desktop box. Miraculously, things like gcc and glibc don't
use it.

Rémi
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Chris Gianelloni]

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

On Thu, 2007-05-17 at 07:57 +0000, Duncan wrote:
> "Caleb Tennis" <caleb@gentoo.org> posted
> 35060.192.168.2.155.1179337715.squirrel@www.aei-tech.com, excerpted below,
> on  Wed, 16 May 2007 13:48:35 -0400:
> 
> > I have no problem waiting for 2007.1, if Gnome and KDE don't mind.  I
> > don't know what hackery has to take place to do that, but I'm sure
> > someone out there does.
> 
> What sort of timing are we looking at for 2007.1 anyway?  With .0 delayed 
> as it was, is .1 going to be relatively quick, say August, or are we 
> looking at November now?

We're taking a couple months off.  We deserve it.  There's no way we're
making an August release.  If you would have checked
http://releng.gentoo.org before asking, you wouldn't have needed to ask.
*grin*

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: stabilizing expat 2.0.0

[Duncan]

Chris Gianelloni <wolf31o2@gentoo.org> posted
1179424776.24852.3.camel@workbox.quova.com, excerpted below, on  Thu, 17
May 2007 10:59:36 -0700:

> We're taking a couple months off.  We deserve it.  There's no way we're
> making an August release.  If you would have checked
> http://releng.gentoo.org before asking, you wouldn't have needed to ask.

Thanks, both for the answer, and the gentle prod. =8^)

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

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Chris Gianelloni]

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

On Wed, 2007-05-16 at 13:48 -0400, Caleb Tennis wrote:
> >> No.  It would have been ideal if we would have done it with the release.
> >> Now, it means people *will* need to use revdep-rebuild as soon as they
> >> install their shiny new system if they use binary packages.  People
> >> coming from stage3 would be fine, of course.
> >>
> >
> 
> I would have been happy to do that, but honestly Chris, the thought of approaching
> you and asking you to bump something like that into 2007.0 scared the crap out of
> me.  You seemed way overburdened for the release as it was.

I can totally understand this feeling.  Releases are stressful.

At the same time, I want to make sure that nobody feels afraid to come
to us with things like this.  Releases are the perfect time to make
changes that would otherwise be intrusive, since we can use the profiles
to make these sorts of changes, keeping them from affecting users until
they're ready.  We fully encourage people to come to us with changes
like this so we can help ease transitions for our users.  After all, new
releases are generally just a media refresh, but if we can use them to
make things better for our users, we should.

> I have no problem waiting for 2007.1, if Gnome and KDE don't mind.  I don't know
> what hackery has to take place to do that, but I'm sure someone out there does.

It's simple.  You mask expat-2.0.0 on all the current profiles, we mark
it stable in the snapshot and don't have it masked in the 2007.1
profile.  When we release (actually right before), we mark the package
stable in the tree.  We document the expat upgrade as part of the
profile upgrade guide, and we're done.  Users using a <=2007.0 profile
never see the upgrade.  New users use the new expat.  Users changing to
the 2007.1 profile run revdep-rebuild.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Rémi Cardona]

Chris Gianelloni wrote:
> It's simple.  You mask expat-2.0.0 on all the current profiles, we mark
> it stable in the snapshot and don't have it masked in the 2007.1
> profile.  When we release (actually right before), we mark the package
> stable in the tree.  We document the expat upgrade as part of the
> profile upgrade guide, and we're done.  Users using a <=2007.0 profile
> never see the upgrade.  New users use the new expat.  Users changing to
> the 2007.1 profile run revdep-rebuild.

+1

Now, how can we do this? Could we start changing the profiles right now?
(I guess people on ~arch will need to unmask it to not downgrade).
Should this be brought to the next council meeting?

Chris, I could write a small paragraph for whatever GWN explaining what
stable and unstable users will have to do if you want.

Cheers,

Rémi
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Vlastimil Babka]

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

Rémi Cardona wrote:
> Chris Gianelloni wrote:
>> It's simple.  You mask expat-2.0.0 on all the current profiles, we mark
>> it stable in the snapshot and don't have it masked in the 2007.1
>> profile.  When we release (actually right before), we mark the package
>> stable in the tree.  We document the expat upgrade as part of the
>> profile upgrade guide, and we're done.  Users using a <=2007.0 profile
>> never see the upgrade.  New users use the new expat.  Users changing to
>> the 2007.1 profile run revdep-rebuild.
> 
> Now, how can we do this? Could we start changing the profiles right now?
> (I guess people on ~arch will need to unmask it to not downgrade).

That can be avoided if you make an artifical revbump that won't change
anything, just have stable keywords, and you mask that revision
specifically.
- --
Vlastimil Babka (Caster)
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGTKEqtbrAj05h3oQRAsKEAJ9Nwh6jww9Tut9VtXnHIPuLXHUnUQCcCoSQ
T/34IkQDJqh6IOGX7rME1fw=
=Bssx
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Chris Gianelloni]

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

On Thu, 2007-05-17 at 20:38 +0200, Vlastimil Babka wrote:
> > Now, how can we do this? Could we start changing the profiles right now?
> > (I guess people on ~arch will need to unmask it to not downgrade).
> 
> That can be avoided if you make an artifical revbump that won't change
> anything, just have stable keywords, and you mask that revision
> specifically.

Exactly.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Chris Gianelloni]

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

On Thu, 2007-05-17 at 20:33 +0200, Rémi Cardona wrote:
> Chris Gianelloni wrote:
> > It's simple.  You mask expat-2.0.0 on all the current profiles, we mark
> > it stable in the snapshot and don't have it masked in the 2007.1
> > profile.  When we release (actually right before), we mark the package
> > stable in the tree.  We document the expat upgrade as part of the
> > profile upgrade guide, and we're done.  Users using a <=2007.0 profile
> > never see the upgrade.  New users use the new expat.  Users changing to
> > the 2007.1 profile run revdep-rebuild.
> 
> +1
> 
> Now, how can we do this? Could we start changing the profiles right now?

Considering we already have a 2.0.0 ebuild, we do the following:

- Mask >=2.0.0-r9 (this allows for security bumps, if necessary, number
can be adjusted)
- Copy 2.0.0 to 2.0.0-r9
- When we make a new 2007.1 profile, don't mask >=2.0.0-r9
- Stable 2.0.0-r9 in the 2007.1 snapshot and mark it stable in the tree
with the release
- ???
- Profit!

> (I guess people on ~arch will need to unmask it to not downgrade).

Well, with what I have said, there's room for version bumps, if
required.  It also means ~arch people don't have to do anything.  There
won't be any downgrade and we simply never mark anything below 2.0.0-r9
stable to keep stable users safe.

> Should this be brought to the next council meeting?

Is that really necessary?  What can the Council do that we cannot agree
upon here as civil adults?  I think we can agree to do this ourselves.
I can definitely agree to it from a Release Engineering standpoint.  It
would work quite well and is beneficial to our users.

> Chris, I could write a small paragraph for whatever GWN explaining what
> stable and unstable users will have to do if you want.

Sure.  However, if we did follow my draft plan above, there would be no
need.  Users running ~arch have probably hit this already by now, so I
don't think we would be informing too many people.  That being said, it
would make a cool article.  Even if just to show that, yes, we really do
care for our users and think about ways to reduce the impact on their
systems.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: stabilizing expat 2.0.0

[Steve Long]

Chris Gianelloni wrote:
>> Now, how can we do this? Could we start changing the profiles right now?
> 
> Considering we already have a 2.0.0 ebuild, we do the following:
> 
> - Mask >=2.0.0-r9 (this allows for security bumps, if necessary, number
> can be adjusted)
> - Copy 2.0.0 to 2.0.0-r9
> - When we make a new 2007.1 profile, don't mask >=2.0.0-r9
> - Stable 2.0.0-r9 in the 2007.1 snapshot and mark it stable in the tree
> with the release
> - ???
> - Profit!
> 
 
>> Should this be brought to the next council meeting?
> 
> Is that really necessary?  What can the Council do that we cannot agree
> upon here as civil adults?  I think we can agree to do this ourselves.
> I can definitely agree to it from a Release Engineering standpoint.  It
> would work quite well and is beneficial to our users.
> 
++

>> Chris, I could write a small paragraph for whatever GWN explaining what
>> stable and unstable users will have to do if you want.
> 
> Sure.  However, if we did follow my draft plan above, there would be no
> need.  Users running ~arch have probably hit this already by now, so I
> don't think we would be informing too many people.  That being said, it
> would make a cool article.  Even if just to show that, yes, we really do
> care for our users and think about ways to reduce the impact on their
> systems.
> 
Personally I found the outline above about how such a tree-wide change is
implemented to be fascinating technically, so I think an article is a great
idea, especially if that could be fleshed out to cover metadata format
changes and the like. I have no idea exactly what other types of changes
would require such a move, but I'd love to read about them.

A 90% revdep-rebuild would definitely tempt me to reinstall tho :)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: stabilizing expat 2.0.0

[Rémi Cardona]

Chris Gianelloni wrote:
> No.  It would have been ideal if we would have done it with the release.

Exactly my point. Let's do it for the next release if neither Gnome nor
KDE folks can predict our/their next releases.

Cheers,
Rémi
--
gentoo-dev@gentoo.org mailing list