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@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
