Multilib Middle-Ground

[Les Mikesell]

Jeff Spaleta wrote:
>
>>  Perhaps, but fedora is one of the worst distributions to keep anything
>> working consistently for years because of its rapid internal changes. If you
>> can't use something consistent as the example for a standard, how is it ever
>> going to improve?
> 
> Are you arguing for backwards compatibility inside Fedora.. or arguing
> cross-compatibility across distributions? Are are you just asking for
> maximal compatibility for everything?

Yes, all of the above - but it has to start somewhere. One of the 
reasons I've liked unix-like systems for 20+ years is that even though 
they misspelled the system call version of create, they never improved 
it by fixing the spelling and breaking everyone's subsequent work.  But 
there are any number of changes of that nature that happen in linux 
distributions.

> Fedora isn't going to solve the cross-distribution problem on its own.
> Fedora isn't going to even solve the backwards compatibility problem
> on its own.  And its certaintly not going to solve the multi-arch
> compatibility problem on its own.  This is only going to get solved if
> someone who cares gets all the stakeholders talking in a constructive
> forward looking conversation.  You care...but I very much doubt you
> have the necessary skills to make a constructive dialog happen.

No, I have some experience with things that have broken, but that's all.

> We are only going to make headway on any of this by getting the
> distributions and upstream projects together and figuring out what
> needs and can be standardized.

Is there even a space where any of this is documented?  Or regression 
tests for existing library interfaces - or the kernel?

> Making backwards and cross compatibility work in a
> meaningful way is not something we can impose on the open ecosystem.

You can't impose it but maybe it would help to point out regressions and 
give people a longer choice about upgrading.

> All we can do internally is to have a policy with regard to backwards
> compatibilty...and we do. We have a process by which compat packaging
> crap can be generated.

I'd describe this the other way around, with the thing that has 
regressions that require compatibility help as the crap, not the part 
that actually keeps things working.

> Here's an exercise for you.  Attempt to figure out which upstream
> library projects care about doing backwards compatibility and are
> doing the necessary things so we can make use of symbol versioning and
> other technical measures to use in our packaging depchains.  That is
> the starting point for a discussion for where backwards compatibility
> stands in the open source ecosystem.

Can't you just always provide at least 2 versioned libraries?  One 
essentially equivalent to the latest released RHEL or Centos version(s) 
and the other whatever flavor is current?  And unless apps need 
something new, build them against the stable version.

> If enough upstream projects are
> not doing what is necessary to make backwards compatibility easy to
> package, then there's no point in attempting to fix the problem at the
> distribution level.  If enough individual upstream projects are doing
> what it takes, then we can attempt to define a set of libraries inside
> Fedora which form a 'framework' that users can more readily rely on to
> behave when targetting their own in house code against.
> 
> But unless individual upstream projects want backwards compatibility
> to matter...its not going to matter.

I'd like to think of distributions as having some editorial control over 
what they ship.  If someone writes crap you don't have to publish it. 
Or at least overlap old/new versions for a complete version run.

-- 
   Les Mikesell
    lesmikesell at gmail.com