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
