Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL,gimp, gimp1_3
R.I.P. Deaddog [EMAIL PROTECTED] writes:
|Given that gimp1_3 obsoletes gimp-data-min, and gimp provides
|gimp-data-min, if rpm -U gimp1_3 doesn't want to uninstall gimp, I
|think that would be a bug in RPM?
|
| they both provides/obsoletes it, so there's no bug there.
And I think the gimp-data-min shouldn't be obsoleted/provided by
gimp1_3, since this is an really old artifact from 1.0-1.2 days.
If gimp-data-min package still exist for now, it won't conflict with
gimp1_3, so there's not much point to provide/obsolete gimp-data-min in
gimp1_3.
|The main difference between the two lies in other packages'
requirements. If
|gimp-1.2 provides hackgimp, then other packages can depend on hackgimp
when
|they mean gimp = 1.1. I don't think this is a good thing. For one, it
|pretty much fixes the definition of hackgimp to be gimp = 1.1
forever
|(or at least until 1.4 comes out). For another, it's a bit weird
conceptually
|for hackgimp to mean the old 1.1 development tree rather than the
|current development tree.
|
| the point is that we do not want to break updates.
| we cannot change the past, only the future, so here's the hackgimp
| definition.
This is true, for gimp 1.2. But for 1.3, I guess we don't need to
provide/obsolete hackgimp again.
we do want want to keep them.
some day, gimp1_3 will become gimp-1.4.x (or gimp-2.0.x once the troll
on gimp development mls end), and we still want to keep this
historical stuff.
ok the odds're high nobody'll try to update from a so old distro but
the better we can do for updates, the better we will.
now, having buglets in these update facilities can happen.
if so, we'll fix them.
i fixed gimp with andi help
i've yet fixed gimp1_3 since it does not build for now (i've problem
with libtool as %install stage) and since i'm busy with other projects
such as porting our tools to the gtk2 perl binding and using its new
features:
- fix all remaining bugs added by the move
- make sure install stil works
- use size group when needed (eg in menus_launchers.pl) in order to
get rid of bad reports about widget alignment
- use optionmenu rather than comboboxes when needed
- diskdrake, draksec, drakxservices: use GtkTrees instead of
packtables
- drakconnect, drakfloppy : grey hidden stuff instead of inlarging
windows at runtime (idem everywhere needed)
what's more, i would like to:
- fix some bugs in bugzilla
- renew mdk-rpm howto:
o devel provides
o new macros
o lib64
o rpmlint / distriblint
o new auto{req,provides} for perl
o always obsoletes with tag
- fix explanations: move them to explanations.pm, import them into
common and standalone
- fix stock items usage in interactive tools by providing
interactive::{gtk,newt,...} -ok -cancel helpers
and i've to do this before going in hollydays.
so if you want me to merge in your changes, explain them and do not do
too intrusive changes such as cleaning the spec by the same way so
that i can see what you do change, since that'll not be my higher
priority ...
|but when do you upload those fixed packages (at least those
|belonging to contribs) ?
|
|I already uploaded the .spec files, as I explained in the previous
|message. I realize that the cooker submission instructions say to
|upload the .src.rpm.
|
| it would just be easier if you send me the spec files for my packages
Titi, would you mind if I'm submitting changes to you too?
no. but i'll review them
Beside the stuff Andy mentioned, I have heavily modified quite a lot
of places so that many old artifacts from 1.1/1.2 days are gone,
i probably won't take them :-(
and bring back color modules etc.
let see
Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL,gimp, gimp1_3
Andi Payn [EMAIL PROTECTED] writes: A quick urpmf --media main-cooker,contrib-cooker --provides |grep gimp-data-min shows nothing relying on this; is that a good enough test to be sure it's safe, or do we also have to make sure that non-Mandrake-provided packages (plf, nexedi, whatever) don't need it? these're there to help updating from older releases. i guess we can remove the provides from gimp1_3 and keept the obsoletes ... X.Y.Z in both gimps. [about hackgimp being provided and obsoleted by both] | we cannot change the past, only the future, so here's the | hackgimp definition. This is true, for gimp 1.2. But for 1.3, I guess we don't need to provide/obsolete hackgimp again. of course we do since we expect gimp1_3 to became the new stable gimp one day ... Again, is it ok to remove hackgimp now when it was already in the 9.1 release of gimp1_3? (The same test as above shows nothing in Cooker requires hackgimp either.) we cannot change the past so we want to keep the needed stuff to update from older releases
Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL,gimp, gimp1_3
Andi Payn [EMAIL PROTECTED] writes: As I mentioned in my last email, there are problems in at least these three pairs of packages that prevent the old and new versions from coexisting, even though this wasn't true with recent versions: libsigc++1.0-devel and libsigc++1.2-devel; libmysql10 and libmysql12; and gimp and gimp1_3. i've no problem in having both gimp-1.2 and gimp1_3-1.3 installed at the same moment Do you have the latest versions of gimp, gimp1_3, and rpm? [EMAIL PROTECTED] ~/rpm/SPECS $ rpm -qa \*gimp\* rpm | sort gimp-1.2.5-2mdk gimp-perl-1.2.5-2mdk libgimp1.2_1-1.2.5-1mdk libgimp1.2-1.2.5-2mdk libgimp14-1.3.14-2mdk libgimpprint1-4.2.5-18mdk rpm-4.2-8mdk I retested by taking a stock 9.1 machine, urpmi'ng enough of cooker to the point where I could install the current versions of gimp and gimp1_3, then upgrading gimp, then upgrading gimp1_3, and it wanted to uninstall gimp. note that i install these packages when i build them, and that some dependancies may have changed since and may preventing installing them *now* Given that gimp1_3 obsoletes gimp-data-min, and gimp provides gimp-data-min, if rpm -U gimp1_3 doesn't want to uninstall gimp, I think that would be a bug in RPM? they both provides/obsoletes it, so there's no bug there. By the way, gimp-1.2.5 provides hackgimp. I don't think this is right, is it? of course it is: compatibility with previous distros when we had both stable gimp-1.0 and development hackgimp-1.1.x which became the new gimp-1.2.0 But this is better served by having it obsolete hackgimp 1.2, rather than providing hackgimp. of course yes The main difference between the two lies in other packages' requirements. If gimp-1.2 provides hackgimp, then other packages can depend on hackgimp when they mean gimp = 1.1. I don't think this is a good thing. For one, it pretty much fixes the definition of hackgimp to be gimp = 1.1 forever (or at least until 1.4 comes out). For another, it's a bit weird conceptually for hackgimp to mean the old 1.1 development tree rather than the current development tree. the point is that we do not want to break updates. we cannot change the past, only the future, so here's the hackgimp definition. And of course it means that the hackgimp name is no longer available for 1.3, 1.5, 1.9, etc. if we do not want to break updates, yes. this is why i named the new gtk+2 branch gimp1_3 in order to be able to have both gtk+-1 and gtk+-2 installed at the same time. same thing for abiword2, apache2, imlib2, libalsa2, libgnome*, ... (although that may not be a problem if the new gimp1_3-style names are preferred). they're obvioulsy more suited in order to support both update from previously released distros and cohabitation of different trees. but when do you upload those fixed packages (at least those belonging to contribs) ? I already uploaded the .spec files, as I explained in the previous message. I realize that the cooker submission instructions say to upload the .src.rpm. it would just be easier if you send me the spec files for my packages
Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL,gimp, gimp1_3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thierry Vignaud wrote: |Given that gimp1_3 obsoletes gimp-data-min, and gimp provides |gimp-data-min, if rpm -U gimp1_3 doesn't want to uninstall gimp, I |think that would be a bug in RPM? | | they both provides/obsoletes it, so there's no bug there. And I think the gimp-data-min shouldn't be obsoleted/provided by gimp1_3, since this is an really old artifact from 1.0-1.2 days. If gimp-data-min package still exist for now, it won't conflict with gimp1_3, so there's not much point to provide/obsolete gimp-data-min in gimp1_3. |The main difference between the two lies in other packages' requirements. If |gimp-1.2 provides hackgimp, then other packages can depend on hackgimp when |they mean gimp = 1.1. I don't think this is a good thing. For one, it |pretty much fixes the definition of hackgimp to be gimp = 1.1 forever |(or at least until 1.4 comes out). For another, it's a bit weird conceptually |for hackgimp to mean the old 1.1 development tree rather than the |current development tree. | | the point is that we do not want to break updates. | we cannot change the past, only the future, so here's the hackgimp | definition. This is true, for gimp 1.2. But for 1.3, I guess we don't need to provide/obsolete hackgimp again. |but when do you upload those fixed packages (at least those |belonging to contribs) ? | |I already uploaded the .spec files, as I explained in the previous |message. I realize that the cooker submission instructions say to |upload the .src.rpm. | | it would just be easier if you send me the spec files for my packages Titi, would you mind if I'm submitting changes to you too? Beside the stuff Andy mentioned, I have heavily modified quite a lot of places so that many old artifacts from 1.1/1.2 days are gone, and bring back color modules etc. Abel - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Cex2QVLh8cZxhv8RAjpuAJ49HLNTTNQtTdWWgSGBhQQwhtnRYACfeHSQ UUlG6iqp3T56kirx1K2P/+I= =MsUv -END PGP SIGNATURE-
Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL, gimp, gimp1_3
For some reason, I haven't seen Thierry's message yet, so I'll reply to Abel's reply to it On Monday 07 July 2003 14:56, R.I.P. Deaddog wrote: Thierry Vignaud wrote: |Given that gimp1_3 obsoletes gimp-data-min, and gimp provides |gimp-data-min, if rpm -U gimp1_3 doesn't want to uninstall gimp, I |think that would be a bug in RPM? | | they both provides/obsoletes it, so there's no bug there. OK, if RPM is working properly, if you install them both at the same time, it will install both--but if you have one, installing or upgrading the other will uninstall the first. And that is exactly the behavior I'm seeing. Worse, once you have the two installed, if a new 1.2 package comes out without a new 1.3, or vice-versa, upgrading will remove the other; you'll have to wait until new versions of both packages are available to upgrade properly. This is a bit unintuitive, to put it mildly. And I think the gimp-data-min shouldn't be obsoleted/provided by gimp1_3, since this is an really old artifact from 1.0-1.2 days. If gimp-data-min package still exist for now, it won't conflict with gimp1_3, so there's not much point to provide/obsolete gimp-data-min in gimp1_3. OK, that would solve the problem just as well, and it's easier. But, is it too late to remove gimp-data-min from gimp1_3 when it was provided by the gimp1_3 package in 9.1 contribs? A quick urpmf --media main-cooker,contrib-cooker --provides |grep gimp-data-min shows nothing relying on this; is that a good enough test to be sure it's safe, or do we also have to make sure that non-Mandrake-provided packages (plf, nexedi, whatever) don't need it? [about hackgimp being provided and obsoleted by both] | we cannot change the past, only the future, so here's the hackgimp | definition. This is true, for gimp 1.2. But for 1.3, I guess we don't need to provide/obsolete hackgimp again. Again, is it ok to remove hackgimp now when it was already in the 9.1 release of gimp1_3? (The same test as above shows nothing in Cooker requires hackgimp either.) | it would just be easier if you send me the spec files for my packages OK, done.
Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL,gimp, gimp1_3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andi Payn wrote: | But, is it too late to remove gimp-data-min from gimp1_3 when it was provided | by the gimp1_3 package in 9.1 contribs? Never too late. Nothing requires gimp-data-min, except gimp itself. And it came from gimp-1.0/1.1 days. Abel |This is true, for gimp 1.2. But for 1.3, I guess we don't need to |provide/obsolete hackgimp again. | | Again, is it ok to remove hackgimp now when it was already in the 9.1 release | of gimp1_3? (The same test as above shows nothing in Cooker requires hackgimp | either.) - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Cf3dQVLh8cZxhv8RAl6hAKDBtYH0kE5UBoZkjX9M6p7JsyYHwQCcCGv4 /KxtORT3Fxzp/qBQFquWDPs= =eTxc -END PGP SIGNATURE-
Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL,gimp, gimp1_3
Andi Payn [EMAIL PROTECTED] writes: As I mentioned in my last email, there are problems in at least these three pairs of packages that prevent the old and new versions from coexisting, even though this wasn't true with recent versions: libsigc++1.0-devel and libsigc++1.2-devel; libmysql10 and libmysql12; and gimp and gimp1_3. i've no problem in having both gimp-1.2 and gimp1_3-1.3 installed at the same moment By the way, gimp-1.2.5 provides hackgimp. I don't think this is right, is it? of course it is: compatibility with previous distros when we had both stable gimp-1.0 and development hackgimp-1.1.x which became the new gimp-1.2.0 I can see why it might want to obsolete old versions of hackgimp, so I left the Obsoletes: hackgimp, but added a %version-%release in. that's fine I also changed the corresponding Obsoletes tag in gimp1_3. This means that users will have to upgrade both to upgrade either. thanks. but when do you upload those fixed packages (at least those belonging to contribs) ?
Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL, gimp, gimp1_3
On Sunday 06 July 2003 11:13, Thierry Vignaud wrote: Andi Payn [EMAIL PROTECTED] writes: As I mentioned in my last email, there are problems in at least these three pairs of packages that prevent the old and new versions from coexisting, even though this wasn't true with recent versions: libsigc++1.0-devel and libsigc++1.2-devel; libmysql10 and libmysql12; and gimp and gimp1_3. i've no problem in having both gimp-1.2 and gimp1_3-1.3 installed at the same moment Do you have the latest versions of gimp, gimp1_3, and rpm? I retested by taking a stock 9.1 machine, urpmi'ng enough of cooker to the point where I could install the current versions of gimp and gimp1_3, then upgrading gimp, then upgrading gimp1_3, and it wanted to uninstall gimp. Given that gimp1_3 obsoletes gimp-data-min, and gimp provides gimp-data-min, if rpm -U gimp1_3 doesn't want to uninstall gimp, I think that would be a bug in RPM? By the way, gimp-1.2.5 provides hackgimp. I don't think this is right, is it? of course it is: compatibility with previous distros when we had both stable gimp-1.0 and development hackgimp-1.1.x which became the new gimp-1.2.0 But this is better served by having it obsolete hackgimp 1.2, rather than providing hackgimp. The main difference between the two lies in other packages' requirements. If gimp-1.2 provides hackgimp, then other packages can depend on hackgimp when they mean gimp = 1.1. I don't think this is a good thing. For one, it pretty much fixes the definition of hackgimp to be gimp = 1.1 forever (or at least until 1.4 comes out). For another, it's a bit weird conceptually for hackgimp to mean the old 1.1 development tree rather than the current development tree. And of course it means that the hackgimp name is no longer available for 1.3, 1.5, 1.9, etc. (although that may not be a problem if the new gimp1_3-style names are preferred). but when do you upload those fixed packages (at least those belonging to contribs) ? I already uploaded the .spec files, as I explained in the previous message. I realize that the cooker submission instructions say to upload the .src.rpm. However, I was told before that when I'm uploading a large package and the only change from the existing version is the specfile it's better to just upload the specfile. If that's wrong, I can upload the .src.rpm files as well.
[Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL, gimp, gimp1_3
As I mentioned in my last email, there are problems in at least these three pairs of packages that prevent the old and new versions from coexisting, even though this wasn't true with recent versions: libsigc++1.0-devel and libsigc++1.2-devel; libmysql10 and libmysql12; and gimp and gimp1_3. In all three cases, the problem is that both package both provide and obsolete the same virtual package name, so the best solution seems to be to remove the obsoletes tag. For gimp and libsigc++, because both packages are current, I fixed both. For MySQL, because the old version is no longer in cooker, I only fixed the new version. Presumably, anyone who doesn't already have libmysql10 probably doesn't need it. However, I haven't checked to make sure nothing current depends on it. If something does, it obviously needs to be reinstated in the current repository; if nothing does, then maybe my fix isn't necessary. By the way, gimp-1.2.5 provides hackgimp. I don't think this is right, is it? I can see why it might want to obsolete old versions of hackgimp, so I left the Obsoletes: hackgimp, but added a %version-%release in. I also changed the corresponding Obsoletes tag in gimp1_3. This means that users will have to upgrade both to upgrade either. Since some of these are large packages, and in every case only the specfile has been changed, I only uploaded the specfiles: * libsigc++1.0.spec (libsigc++1.0-1.0.4-7mdk.src.rpm) * libsigc++1.2.spec (libsigc++1.2-1.2.5-2mdk.src.rpm) * MySQL.spec (MySQL-4.0.13-3mdk.src.rpm) * gimp.spec (gimp-1.2.5-3mdk.src.rpm) * gimp1_3.spec (gimp1_3-1.3.14-3mdk.src.rpm) Note the name change from libsigc++-1.0 to libsigc++1.0 (to correspond with 1.2). The binary packages will have a similar name change (and libsigc++-examples will become libsigc++1.0-examples). Also note the fact that it's 2 releases later than the one in the repository, because I uploaded a -6mdk earlier in the week. Feel free to disregard the earlier one, and renumber this to -6 if you want.
