Re: [Cooker] Re: Versioning for multiple releases: a modest suggestion
On Fri, 7 Nov 2003 00:20:11 +0100 (CET) Christiaan Welvaart <[EMAIL PROTECTED]> wrote: > > On Fri, 7 Nov 2003 01:09, Buchan Milne wrote: > > > If one mixes packages from various releases, and something does not work, > the dependencies are not correct. Epoch should not be used to fix binary > incompatibilities. > > Example: to allow upgrading & downgrading mozilla/galeon/etc., all > moz libraries that are used by other packages must be in a separate > package, and have a major version number. If binary incompatible compiler > versions must be taken into account, the compiler version must be added as > well. > > So instead of > > libxpcom.so in package mozilla, you have > libxpcom-1.4-3.3.so.0.0 in package libmozilla1.4_3.3-1.4-2mdk >(libxpcom of mozilla 1.4 compiled with g++ 3.3, binary incompatible > with libxpcom-1.4-3.1.so.0.0 and libxpcom-1.3-3.3.so.0.0) >(the exact placement of the library versions may be different, I don't > know what's best) > > Then it is possible to have mozilla 1.5 installed, together with a galeon > that requires mozilla 1.3. Upgrading a mdk 9.1 with these packages to mdk > 9.2 does not upgrade mozilla, but does upgrade galeon, and everything > still works. Maybe it works in this case ( I don't know if it does), but it's definitely not guaranteed to work in all situations. It's not just gcc that breaks binary compatibility, it's also other libraries, or libraries used by libraries. Remember the nightmare when going from libpng2 to libpng3? Sometimes compatibility even breaks without the library changing its soname...sometimes glibc breaks binary compatibility...sometimes this, sometimes that... Sometimes you know these things before you run into them, and sometimes not. But having to set dependencies for this makes things too hard to maintain. Who is gonna test it, and who is gonna set all these dependencies? Up to now the resolution was to advise to not mix packages from different releases, because sometimes things work, and sometimes things break in weird ways. I think we should stick to that, I wouldn't dare to advise to trust on dependencies, whatever the amount of time that's being put in testing and setting it all up. Mixing packages is Russian roulette, and should be advertised as such. When people choose to do that, we won't stop them. But when things break because a 9.1 medium (texstar's kde for 9.1) has newer versions then a new mdk release, then an Epoch can fix that. That's a goal that we can make. The goal you have seems unrealistic to me. I just wish it was possible, but I don't see it happening. -- Marcel Pol
Re: [Cooker] Re: Versioning for multiple releases: a modest suggestion
On Fri, 07 Nov 2003 09:46:16 +0100, Gwenole Beauchesne wrote: > On Fri, 7 Nov 2003, Christiaan Welvaart wrote: > >> Example: to allow upgrading & downgrading mozilla/galeon/etc., all moz >> libraries that are used by other packages must be in a separate package > > Indeed Mozilla must still be a correctly libified package, at least for > biarch installation. And, for other packages (e.g. Galeon, OOo) to use > Mozilla system libraries. > > Fred, please proceed ASAP. It seems you have absolutely NO understanding of how mozilla is currently architecture, otherwise you wouldn't ask that.. Mozilla WON'T be libified until Mozilla folks released GRE (Gecko Runtime Engine) which will allow to clearly split Mozilla network (necko) and HTML engine (gecko) from Mozilla interface.. Until this is done and enabled in Mozilla code, you CAN'T libified it.. When GRE will be available, we will be able to split mozilla libraries (which are already somehow libified, for nspr and nss) from mozilla programs. -- Frederic Crozat MandrakeSoft
Re: [Cooker] Re: Versioning for multiple releases: a modest suggestion
On Fri, 7 Nov 2003, Christiaan Welvaart wrote: > Example: to allow upgrading & downgrading mozilla/galeon/etc., all moz > libraries that are used by other packages must be in a separate package Indeed Mozilla must still be a correctly libified package, at least for biarch installation. And, for other packages (e.g. Galeon, OOo) to use Mozilla system libraries. Fred, please proceed ASAP. Thanks, Gwenole.
Re: [Cooker] Re: Versioning for multiple releases: a modest suggestion
On Fri, 7 Nov 2003, Leon Brooks wrote: > On Fri, 7 Nov 2003 01:09, Buchan Milne wrote: If one mixes packages from various releases, and something does not work, the dependencies are not correct. Epoch should not be used to fix binary incompatibilities. Example: to allow upgrading & downgrading mozilla/galeon/etc., all moz libraries that are used by other packages must be in a separate package, and have a major version number. If binary incompatible compiler versions must be taken into account, the compiler version must be added as well. So instead of libxpcom.so in package mozilla, you have libxpcom-1.4-3.3.so.0.0 in package libmozilla1.4_3.3-1.4-2mdk (libxpcom of mozilla 1.4 compiled with g++ 3.3, binary incompatible with libxpcom-1.4-3.1.so.0.0 and libxpcom-1.3-3.3.so.0.0) (the exact placement of the library versions may be different, I don't know what's best) Then it is possible to have mozilla 1.5 installed, together with a galeon that requires mozilla 1.3. Upgrading a mdk 9.1 with these packages to mdk 9.2 does not upgrade mozilla, but does upgrade galeon, and everything still works. Christiaan
Re: [Cooker] Re: Versioning for multiple releases: a modest suggestion
> On Fri, 7 Nov 2003 01:09, Buchan Milne wrote:
>>> 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.
>
> How big can the epoch be?
Existing, or absolute maximum?
$ rpm -qp --qf "%{EPOCH}\n" libarts1-1.1.3-7mdk.i586.rpm
3001
:-(
But, 30092001 is still bigger than 30091001
> If you used release * 100 + existing, would
> that work? So if a package was up to epoch 42, you would get 9242 for
> the current release and 10042 for the same package aimed at 10.0.
Yes, this is the idea.
>
> Next question, how about switching to even release numbers for stable
> releases and odd for Cooker? That would make the epoch 9342 for the
> pre-10.0 Cooker, 10042 for the 10.0 release, 10142 for the post-10.0
> Cooker, 10242 for the next release (10.2, there is no 10.1), presuming
> that no version bumps happened in between times.
I had wondered about possibly having an approach closer to what FreeBSD
has, where we have a 9.x branch and a 10.x branch, and after a certain
point, end-users should be happy to test with it, and at some point goes
into maintenance.
It might be better to combind both ideas, but this doesn't have too large
an impact on using the epochs or not (although it may be an advantage of
managing the epochs well).
>
> This would violate tradition in that the releases would go 9.2, 10.0,
> 10.2, 10.4, 11.0,... but it would be understandable to anyone used to
> the kernel versioning system and ordinary end-users shouldn't notice
> much or care much either.
>
> If we have room for one more digit, we could use that for the alpha,
> beta and RC releases; so 93042 is the Cooker version of the package,
> 93142 is the alpha, betas run from 93242 to as high as 93542 then RCs
> from 93642 up to (heaven forbid) a potential 93942, then 100042 for the
> 10.0 final.
I don't think the epoch should be abused like that. Sub-release numbers
(ie 0.alpha24.3mdk) are fine for this.
> How much of this could we do without confusing people too much? How
> complex would it be to set up the corresponding RPM macros?
I don't think rpm macros will be a good solution, since any buildrequires
with epoch values will need to be adjusted, so either we're going to be
doing shell arithmetic in rpm macros for the epoch values, or rpm needs to
be appropriately hacked ...
Regards,
Buchan
[Cooker] Re: Versioning for multiple releases: a modest suggestion
On Fri, 7 Nov 2003 01:09, Buchan Milne wrote: >> 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. How big can the epoch be? If you used release * 100 + existing, would that work? So if a package was up to epoch 42, you would get 9242 for the current release and 10042 for the same package aimed at 10.0. Next question, how about switching to even release numbers for stable releases and odd for Cooker? That would make the epoch 9342 for the pre-10.0 Cooker, 10042 for the 10.0 release, 10142 for the post-10.0 Cooker, 10242 for the next release (10.2, there is no 10.1), presuming that no version bumps happened in between times. This would violate tradition in that the releases would go 9.2, 10.0, 10.2, 10.4, 11.0,... but it would be understandable to anyone used to the kernel versioning system and ordinary end-users shouldn't notice much or care much either. If we have room for one more digit, we could use that for the alpha, beta and RC releases; so 93042 is the Cooker version of the package, 93142 is the alpha, betas run from 93242 to as high as 93542 then RCs from 93642 up to (heaven forbid) a potential 93942, then 100042 for the 10.0 final. How much of this could we do without confusing people too much? How complex would it be to set up the corresponding RPM macros? Cheers; Leon
