We need a plan to cover GNOME 2.19 now that its being released.
Normally I would say move 2.18.1 to G:S and keep updating it there, but
in this case we have the /opt/gnome -> /usr move to deal with, we'd
break anyone on 10.2 and older for sure. Any thoughts on what to do?
-JP
--
JP Rosevear
JP Rosevear wrote:
We need a plan to cover GNOME 2.19 now that its being released. Normally I would say move 2.18.1 to G:S and keep updating it there, but in this case we have the /opt/gnome -> /usr move to deal with, we'd break anyone on 10.2 and older for sure. Any thoughts on what to do?
Yes, it is a big change, but I guess it will not break. I am using 10.2+G:U it on my current work desktop without any problems. For older we'll break, because new hal dependent stuff does not compile, which causes breakage of many packages as a consequence (including gedit in the chain). We may need to fix it or disable somehow a not supported subset. Before doing it, please let me know. I plan t backup static snapshot of the very last version of G:S sources and binaries somewhere. And should we continue with 2.19 in Factory or continue there with 2.18? What do you think? -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
For older we'll break, because new hal dependent stuff does not compile, which causes breakage of many packages as a consequence (including gedit in the chain). We may need to fix it or disable somehow a not supported subset.
G:S even as it stands now is very broken on 10.0 so I'd suggest we nuke that target anyway unless someone has the time to put into fixing it. The hal dependency affects 10.1 to a lesser degree as it stands with 2.16 in G:S - would it be possible to do one of the following?: a) Import that hal stuff into G:S and only build on 10.1 (I don't like this idea) b) Have a new project for hal which could then benefit anything else that needs it and change the target for 10.1 to use that project c) Nuke 10.1 as a target too (I don't like this one either)
And should we continue with 2.19 in Factory or continue there with 2.18? What do you think?
Will we get 2.20 in time for 10.3? I think I've suggested it before but maybe G:U could have a Factory target added so we (in this instance) stick with 2.18 in Factory so that we have a stable GNOME release in 10.3 and start building 2.19 in G:U. Then, once 10.3 is released, import the work from G:U into Factory and disable the Factory target on it until the next GNOME development cycle comes around. -- James Ogley james@usr-local-bin.org http://usr-local-bin.org GNOME for openSUSE: http://software.opensuse.org/download/GNOME:/ Help end poverty: http://oxfam.org.uk/in -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Mon, 2007-04-23 at 16:09 +0100, James Ogley wrote:
For older we'll break, because new hal dependent stuff does not compile, which causes breakage of many packages as a consequence (including gedit in the chain). We may need to fix it or disable somehow a not supported subset.
G:S even as it stands now is very broken on 10.0 so I'd suggest we nuke that target anyway unless someone has the time to put into fixing it.
The hal dependency affects 10.1 to a lesser degree as it stands with 2.16 in G:S - would it be possible to do one of the following?:
a) Import that hal stuff into G:S and only build on 10.1 (I don't like this idea) b) Have a new project for hal which could then benefit anything else that needs it and change the target for 10.1 to use that project c) Nuke 10.1 as a target too (I don't like this one either)
And should we continue with 2.19 in Factory or continue there with 2.18? What do you think?
Will we get 2.20 in time for 10.3?
I think I've suggested it before but maybe G:U could have a Factory target added so we (in this instance) stick with 2.18 in Factory so that we have a stable GNOME release in 10.3 and start building 2.19 in G:U. Then, once 10.3 is released, import the work from G:U into Factory and disable the Factory target on it until the next GNOME development cycle comes around.
That sounds like a good plan, at least until we know when 10.3 is going to be released. I suspect we won't have time to get 2.20 in for 10.3. -Gary -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
James Ogley wrote:
a) Import that hal stuff into G:S and only build on 10.1 (I don't like this idea) b) Have a new project for hal which could then benefit anything else that needs it and change the target for 10.1 to use that project
It's possible. But will it work there without a lot of hacking? -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
a) Import that hal stuff into G:S and only build on 10.1 (I don't like this idea) b) Have a new project for hal which could then benefit anything else that needs it and change the target for 10.1 to use that project It's possible. But will it work there without a lot of hacking?
I don't know, copying Danny on this mail to ask his view. (Danny could you sub to opensuse-gnome briefly to discuss this?) -- James Ogley james@usr-local-bin.org http://usr-local-bin.org GNOME for openSUSE: http://software.opensuse.org/download/GNOME:/ Help end poverty: http://oxfam.org.uk/in -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Montag, 23. April 2007, James Ogley wrote:
a) Import that hal stuff into G:S and only build on 10.1 (I don't like this idea) b) Have a new project for hal which could then benefit anything else that needs it and change the target for 10.1 to use that project
It's possible. But will it work there without a lot of hacking?
I don't know, copying Danny on this mail to ask his view.
I don't think that this would work without unknown high number of hacks (maybe not in HAL, but in other applications). You should keep in mind that 'whatdependson hal' give ~377 packages which get triggered to rebuild on a HAL update. You should also keep in mind that a up-to-date HAL (as in factory) need several packages which may need also a update as e.g. udev, libsmbios, pm-utils, policykit ... At least you get maybe trouble if you use a older kernel with current HAL since there are maybe sysfs changes and HAL may not work correct in current version with older kernel. I would avoid a HAL update only for GNOME update, also in OSBS, since this would IMO update the half system. I this case you can also update to a newer openSUSE release. Danny -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
James Ogley wrote:
And should we continue with 2.19 in Factory or continue there with 2.18? What do you think?
Will we get 2.20 in time for 10.3?
I think I've suggested it before but maybe G:U could have a Factory target added so we (in this instance) stick with 2.18 in Factory so that we have a stable GNOME release in 10.3 and start building 2.19 in G:U. Then, once 10.3 is released, import the work from G:U into Factory and disable the Factory target on it until the next GNOME development cycle comes around.
Nice idea, but hard to realize. We need a NO-GO flag for SuSE Autobuild/Factory, otherwise people will modify tens or hundreds of packages in Factory with a lot of minor patches and somebody have to spent several days or weeks with reviewing them and merging when 2.20 will come. I remember this problem from December, when I did /opt/gnome -> /usr move. Proposal: NO-GO package will have a .buildservice file in its repository. .buildservice will contain a string with BS project and package name, where it is maintained. More lines mean, that more versions are maintained. Autobuild team will reject manual updates of these files. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Stanislav Brabec
James Ogley wrote:
And should we continue with 2.19 in Factory or continue there with 2.18? What do you think?
Will we get 2.20 in time for 10.3?
I think I've suggested it before but maybe G:U could have a Factory target added so we (in this instance) stick with 2.18 in Factory so that we have a stable GNOME release in 10.3 and start building 2.19 in G:U. Then, once 10.3 is released, import the work from G:U into Factory and disable the Factory target on it until the next GNOME development cycle comes around.
Nice idea, but hard to realize. We need a NO-GO flag for SuSE Autobuild/Factory, otherwise people will modify tens or hundreds of packages in Factory with a lot of minor patches and somebody have to spent several days or weeks with reviewing them and merging when 2.20 will come.
I remember this problem from December, when I did /opt/gnome -> /usr move.
Proposal:
NO-GO package will have a .buildservice file in its repository.
.buildservice will contain a string with BS project and package name, where it is maintained. More lines mean, that more versions are maintained.
Autobuild team will reject manual updates of these files.
We really need to have factory building in the BuildService. This will avoid all these hacks. If we have release date of end of september for 10.3, I assume that GNOME 2.20 will go in at the last second - but this means that we need to have with Beta1 already a first preview in factory and then follow with each GNOME beta, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
We really need to have factory building in the BuildService. This will avoid all these hacks.
Yes, it is. Or even better, construct FACTORY as a set of BuildService repositories, e. g.: FACTORY=Coresystem+KDE:KDE3+GNOME:STABLE+...
If we have release date of end of september for 10.3, I assume that GNOME 2.20 will go in at the last second - but this means that we need to have with Beta1 already a first preview in factory and then follow with each GNOME beta,
This implies staying to be in sync with GNOME:UNSTABLE for the whole time. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Tue, 2007-04-24 at 14:32 +0200, Stanislav Brabec wrote:
Andreas Jaeger wrote:
We really need to have factory building in the BuildService. This will avoid all these hacks.
Yes, it is. Or even better, construct FACTORY as a set of BuildService repositories, e. g.:
FACTORY=Coresystem+KDE:KDE3+GNOME:STABLE+...
If we have release date of end of september for 10.3, I assume that GNOME 2.20 will go in at the last second - but this means that we need to have with Beta1 already a first preview in factory and then follow with each GNOME beta,
The will be fine, GNOME should be feature frozen by the end of July.
This implies staying to be in sync with GNOME:UNSTABLE for the whole time.
Well, I hate to think this would be in Factory for the first couple of
releases, ie 2.19.1 and 2.19.2 at least. I think we're likely to have a
not-so-useable GNOME during that time. At the same time, I want the
early testing, so figuring out the FACTORY issue is key.
-JP
--
JP Rosevear
On Mon, 2007-04-23 at 09:43 -0400, JP Rosevear wrote:
We need a plan to cover GNOME 2.19 now that its being released. Normally I would say move 2.18.1 to G:S and keep updating it there, but in this case we have the /opt/gnome -> /usr move to deal with, we'd break anyone on 10.2 and older for sure. Any thoughts on what to do?
I think we should rename GNOME:STABLE to GNOME:GNOME-2.16 and GNOME:UNSTABLE to GNOME:GNOME-2.18. We should also create GNOME:GNOME-2.20 for the 2.19 and eventual 2.20 work. GNOME:Community should probably remain as-is. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
I think we should rename GNOME:STABLE to GNOME:GNOME-2.16 and GNOME:UNSTABLE to GNOME:GNOME-2.18. We should also create GNOME:GNOME-2.20 for the 2.19 and eventual 2.20 work. GNOME:Community should probably remain as-is.
I have no problem with that myself but the reason they're named as they are were so that the GNOME:* and KDE:* projects had the same naming style. -- James Ogley james@usr-local-bin.org http://usr-local-bin.org GNOME for openSUSE: http://software.opensuse.org/download/GNOME:/ Help end poverty: http://oxfam.org.uk/in -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Michael Wolf wrote:
On Mon, 2007-04-23 at 09:43 -0400, JP Rosevear wrote:
We need a plan to cover GNOME 2.19 now that its being released. Normally I would say move 2.18.1 to G:S and keep updating it there, but in this case we have the /opt/gnome -> /usr move to deal with, we'd break anyone on 10.2 and older for sure. Any thoughts on what to do?
I think we should rename GNOME:STABLE to GNOME:GNOME-2.16 and GNOME:UNSTABLE to GNOME:GNOME-2.18. We should also create GNOME:GNOME-2.20 for the 2.19 and eventual 2.20 work. GNOME:Community should probably remain as-is.
I would like it, too. But it was rejected in past after a long discussion, so there is only chance to move it out of the BS as an static and no longer updated stuff. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Mon, 2007-04-23 at 18:57 +0200, Stanislav Brabec wrote:
Michael Wolf wrote:
On Mon, 2007-04-23 at 09:43 -0400, JP Rosevear wrote:
We need a plan to cover GNOME 2.19 now that its being released. Normally I would say move 2.18.1 to G:S and keep updating it there, but in this case we have the /opt/gnome -> /usr move to deal with, we'd break anyone on 10.2 and older for sure. Any thoughts on what to do?
I think we should rename GNOME:STABLE to GNOME:GNOME-2.16 and GNOME:UNSTABLE to GNOME:GNOME-2.18. We should also create GNOME:GNOME-2.20 for the 2.19 and eventual 2.20 work. GNOME:Community should probably remain as-is.
I would like it, too. But it was rejected in past after a long discussion, so there is only chance to move it out of the BS as an static and no longer updated stuff.
I definitely pushed back on this, I didn't want to end up with 4 or 5
"supported" build services. However things have changed somewhat - the
length of time until 10.3 means two shipping versions of GNOME probably
and the /opt/gnome -> /usr move wasn't factored in. I guess what we
should do is rename G:U to G:216opt or something, move 2.18 to G:S
(built only for 10.2 and factory) and start in on 2.19 in G:U.
The downside of course is not being able to get more testing on 10.2 -
unless we can get that compatibility package built asap which might make
2.18 feasible on 10.2.
-JP
--
JP Rosevear
JP Rosevear píše v Po 23. 04. 2007 v 14:35 -0400:
On Mon, 2007-04-23 at 18:57 +0200, Stanislav Brabec wrote:
Michael Wolf wrote:
On Mon, 2007-04-23 at 09:43 -0400, JP Rosevear wrote:
We need a plan to cover GNOME 2.19 now that its being released. Normally I would say move 2.18.1 to G:S and keep updating it there, but in this case we have the /opt/gnome -> /usr move to deal with, we'd break anyone on 10.2 and older for sure. Any thoughts on what to do?
I think we should rename GNOME:STABLE to GNOME:GNOME-2.16 and GNOME:UNSTABLE to GNOME:GNOME-2.18. We should also create GNOME:GNOME-2.20 for the 2.19 and eventual 2.20 work. GNOME:Community should probably remain as-is.
I would like it, too. But it was rejected in past after a long discussion, so there is only chance to move it out of the BS as an static and no longer updated stuff.
I definitely pushed back on this, I didn't want to end up with 4 or 5 "supported" build services. However things have changed somewhat - the length of time until 10.3 means two shipping versions of GNOME probably and the /opt/gnome -> /usr move wasn't factored in. I guess what we should do is rename G:U to G:216opt or something, move 2.18 to G:S (built only for 10.2 and factory) and start in on 2.19 in G:U.
Rename is not easily possible. We have to delete project and create (and build) new one with the same package set.
From user side of view, it will cause broken repository.
So it might be better to name them: GNOME_2_16 (or GNOME216, GNOME_2_16_OPT,...) GNOME_2_18 (or GNOME218) and GNOME_2_20 for GNOME 2.19 - if anybody will want to follow its development, simply subscribe and once it will become stable and frozen. I don't know, whether BS supports symlinks to projects to provide GNOME:STABLE (recommended stable branch) and GNOME:UNSTABLE.
The downside of course is not being able to get more testing on 10.2 - unless we can get that compatibility package built asap which might make 2.18 feasible on 10.2.
opt_gnome-compat works well and I am using 10.2+GNOME2.18 without any problems. That is why the repository is so large. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Tue, 2007-04-24 at 14:40 +0200, Stanislav Brabec wrote:
The downside of course is not being able to get more testing on 10.2 - unless we can get that compatibility package built asap which might make 2.18 feasible on 10.2.
opt_gnome-compat works well and I am using 10.2+GNOME2.18 without any problems. That is why the repository is so large.
Nice! If thats the case, I guess there is no real issue, we should
pre-announce that 2.18 is moving to G:S, explain that opt_gnome-compat
is necessary for 10.2, actually move it and then start the 2.19 march in
G:U.
Now, I'm not sure 2.19 is what we want to jam into factory immediately.
Is there anyway we can work around that?
-JP
--
JP Rosevear
Now, I'm not sure 2.19 is what we want to jam into factory immediately. Is there anyway we can work around that?
Does it need a work around? Moving G:U to 2.19 doesn't mean it'll end up in Factory until such time as it's decided to sync it over. Creating a Factory target for G:U (or whatever it might be renamed to) means that we intrepid people who are working on getting it working can risk the usability of our desktops but the general Factory users need not do so at first. -- James Ogley james@usr-local-bin.org http://usr-local-bin.org GNOME for openSUSE: http://software.opensuse.org/download/GNOME:/ Help end poverty: http://oxfam.org.uk/in -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Tue, 2007-04-24 at 14:28 +0100, James Ogley wrote:
Now, I'm not sure 2.19 is what we want to jam into factory immediately. Is there anyway we can work around that?
Does it need a work around? Moving G:U to 2.19 doesn't mean it'll end up in Factory until such time as it's decided to sync it over.
The issue is how to get it back into factory when then time comes. We'd have to carefully make sure every fix going into factory also went into G:U or we assume no major fixes in factory and just patch 2.19 and move it back into factory at somepoint (or merge at that point which would be a real mess).
Creating a Factory target for G:U (or whatever it might be renamed to) means that we intrepid people who are working on getting it working can risk the usability of our desktops but the general Factory users need not do so at first.
Yes, this is definitely what the goal is, just have to figure out those
implementation details.
-JP
--
JP Rosevear
JP Rosevear wrote:
On Tue, 2007-04-24 at 14:40 +0200, Stanislav Brabec wrote:
The downside of course is not being able to get more testing on 10.2 - unless we can get that compatibility package built asap which might make 2.18 feasible on 10.2.
opt_gnome-compat works well and I am using 10.2+GNOME2.18 without any problems. That is why the repository is so large.
Nice! If thats the case, I guess there is no real issue, we should pre-announce that 2.18 is moving to G:S, explain that opt_gnome-compat is necessary for 10.2, actually move it and then start the 2.19 march in G:U.
It is not necessary, unless you have any package still present in /opt/gnome. This package deletes itself automatically after installation, it it considers itself as obsolete. Only minor things don't work, e. g.: - bi-prefix gstreamer plugins path (introduces bi-arch problems). - Compilation against libraries linked against moved libraries before the move. This is a "feature" of libtool. Can be worked-around by a tons of symlinks to .la files or by deleting of these .la files.
Now, I'm not sure 2.19 is what we want to jam into factory immediately. Is there anyway we can work around that?
We can continue to work in GNOME:UNSTABLE. But it needs definitely consultation with Autobuild team. I cannot imagine merging of FACTORY patches to GNOME:UNSTABLE after several months of independent development. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Tue, 2007-04-24 at 15:35 +0200, Stanislav Brabec wrote:
JP Rosevear wrote:
On Tue, 2007-04-24 at 14:40 +0200, Stanislav Brabec wrote:
The downside of course is not being able to get more testing on 10.2 - unless we can get that compatibility package built asap which might make 2.18 feasible on 10.2.
opt_gnome-compat works well and I am using 10.2+GNOME2.18 without any problems. That is why the repository is so large.
Nice! If thats the case, I guess there is no real issue, we should pre-announce that 2.18 is moving to G:S, explain that opt_gnome-compat is necessary for 10.2, actually move it and then start the 2.19 march in G:U.
It is not necessary, unless you have any package still present in /opt/gnome. This package deletes itself automatically after installation, it it considers itself as obsolete.
Things like rcxdm will still look for binaries in /opt/gnome right?
Only minor things don't work, e. g.: - bi-prefix gstreamer plugins path (introduces bi-arch problems). - Compilation against libraries linked against moved libraries before the move. This is a "feature" of libtool. Can be worked-around by a tons of symlinks to .la files or by deleting of these .la files.
Now, I'm not sure 2.19 is what we want to jam into factory immediately. Is there anyway we can work around that?
We can continue to work in GNOME:UNSTABLE. But it needs definitely consultation with Autobuild team. I cannot imagine merging of FACTORY patches to GNOME:UNSTABLE after several months of independent development.
See other mail for possible solutions.
-JP
--
JP Rosevear
JP Rosevear wrote:
opt_gnome-compat works well and I am using 10.2+GNOME2.18 without any problems. That is why the repository is so large.
Nice! If thats the case, I guess there is no real issue, we should pre-announce that 2.18 is moving to G:S, explain that opt_gnome-compat is necessary for 10.2, actually move it and then start the 2.19 march in G:U.
It is not necessary, unless you have any package still present in /opt/gnome. This package deletes itself automatically after installation, it it considers itself as obsolete.
Things like rcxdm will still look for binaries in /opt/gnome right?
No. There is a hack to fix this problem in the gdm package for <=10.2 in BS. I am thinking about several additional hacks, e. g. libtool-fix-opt_gnome-references, which looks as the worst breakage after the move. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Tue, 2007-04-24 at 18:22 +0200, Stanislav Brabec wrote:
JP Rosevear wrote:
opt_gnome-compat works well and I am using 10.2+GNOME2.18 without any problems. That is why the repository is so large.
Nice! If thats the case, I guess there is no real issue, we should pre-announce that 2.18 is moving to G:S, explain that opt_gnome-compat is necessary for 10.2, actually move it and then start the 2.19 march in G:U.
It is not necessary, unless you have any package still present in /opt/gnome. This package deletes itself automatically after installation, it it considers itself as obsolete.
Things like rcxdm will still look for binaries in /opt/gnome right?
No. There is a hack to fix this problem in the gdm package for <=10.2 in BS.
I am thinking about several additional hacks, e. g. libtool-fix-opt_gnome-references, which looks as the worst breakage after the move.
Ok, if we can make 2.18 reasonable on 10.2 then I say we stick with G:U
and G:S only. Now, just have to figure out about 2.19 in factory.
-JP
--
JP Rosevear
participants (7)
-
Andreas Jaeger -
Danny Kukawka -
Gary Ekker -
James Ogley -
JP Rosevear -
Michael Wolf -
Stanislav Brabec