-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 G�tz Waschk wrote: > Am Montag, 3. November 2003, 12:32:58 Uhr MET, schrieb [EMAIL PROTECTED]: > >>I did start naming everyting <version>.92mdk to distinguish them from >>cooker stuff (like we are doing for security updates now). > > That's a start.
And I think we should use it for now until we have a more permanent solution. So, anyone rebuilding cooker packages from Club should do this. >>I would to raise another point here quickly, but it needs its own thread: >>shouldn't we force release specific rpms? Too many people are using cooker >>rpms on stable version. Too many people are using rpms for different >>versions on their stable version. > > > I've already suggested something like this in a previous thread. I > thought about a distribution epoch for all packages, so that official > packages are always newer than backported packages. I agree. This would solve the "Texstar KDE-3.1.4 for 9.1" upgrade problem (which some users are experiencing). I don't think there is any other solution which would provide for this. > This would need > some rpm changes, so that a package built on 9.2 would have an epoch > of 92 and one build on 10.0 would have epoch 100. But this would be a > problem with packages that already has an epoch, as you can use only > integer numbers for the epoch tag. It could also cause some problems for Requires/BuildRequires with epoch values? Any BuildRequires/Requires with an existing Epoch value would need to be bumped also, which makes for some additional 'macro-isation' for the packager, and makes it difficult to automate this. > The problem of your naming is that you have to change it by hand. I'd > like to rebuild a cooker package on a stable distribution version and > have it's release changed automatically. Ideally, we should be able to rebuild SRPMS from cooker on any release automatically, and still be able to upgrade them to a newer distro with older base packages. For instance, say mozilla-1.5 goes into cooker. Say it is rebuilt for 9.1 (well, we have this already with the Club 1.5-0.91mdk package). The user upgrades to 9.2, and mozilla-1.4 doesn't ugrade and the user may end up with some problems. I think it the distribution-specific Epoch is to be used, it needs to be done by RPM, and any epoch in a spec file needs to be incremented with the distro epoch. I don't think it is feasible to do it with rpm macros (since you will have trouble with existing epoch values). BTW, for reference some people may want to read the proposal Fedora has, but note that it doesn't address the "newer packages on old release than on current release"-issue, since their "Vepoch" is used in the release tag. Also, they don't require the use of the "Vepoch" it seems. Regards, Buchan - -- |--------------Another happy Mandrake Club member--------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/qoBKrJK6UGDSBKcRArUTAKC9Ycfc0IlwprZMAclD/N80dc9W8QCgjn3L GS87fvAMgSt8XDXCasQtl1o= =Yy9/ -----END PGP SIGNATURE-----
