On Fri, May 02, 2008 at 02:04:58PM -0500, Les Mikesell wrote: >> >> And not to follow upstream changes? This is not good for fedora. > > Why? You have no qualms about trying to influence what proprietary vendors > do by not shipping things you don't like. Why not do the same where its > more likely to make a useful difference? If fedora doesn't use the latest upstream release it hurts Fedora, not upstream. (and I have absolutely no opinion about 'influencing what proprietary vendors do', it must be sommebody else who said that). >> I >> completely agree with you that incompatible ABI changes are hurting >> free software, but this should be fixed upstream, and not in linux >> distros. > > But as long as you keep shipping things without backwards compatibility you > not only hurt your existing users whose own code will break but you > encourage the practice. It's always possible to add new interfaces instead > of breaking the old ones if they weren't designed to be extensible. We cannot encourage or discourage upstream. We are downstream. Even RHEL don't care (unless I am wrong) about ABI compatibility between releases, it would be too much work. In fedora you can always do compat packages if you like. I would happily review them. I have always been opposed to the 'and the primary package maintainer is not against the idea' in http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages (though I agree with the remaining). So nothing is stopping you to provide old sonames in fedora, except for the amount of work (and maybe primary maintainers disagreeing, but I hope that it won't be a real issue). But backporting bugs from maintained releases to compat release unmaintained upstream and only maintained in distro is a lot of work. >> You could try to approach upstream projects that break ABI >> frequently and try to convince them to avoid breaking ABI if you want >> to, but fedora cannot do anything else than consuming what upstream >> produces. > > If you know something hurts, why keep doing it? Why not maintain stable > kernel and library versions for long periods with the current kernel and > differently-named experimental libs as alternative choices? After some > long interval of concurrent use and compatibility testing the > no-longer-expermental libs could replace the stable versions. It is possible to do the reverse, that is ship compat packages, it is even possible to ship old API. For example I maintain in parallel libnet and libnet10 for quite a long time now (both versions are unmaintained). I cannot do that for other libraries I maintain (notably libdap) it would mean too much work (in reality, I have to do it more or less for EPEL, but in that case somebody else commited to do the backports, since I won't do it). > I think that should depend on what upstream does. Fedora has a fast enough > cycle that waiting for the next release for an incompatible change wouldn't > kill anyone. I am personally in favor of that, that is, try to wait for rawhide to break ABI, except if there is a security issue in old lib, or a very problematic bug, and backporting is not easy. There has been disagreement in the past about that issue. I hope that having bodhi now reduces the amount of ABI breaking in updates. >> What do you propose instead? Not following upstream? > > Just not breaking anything that already works. If upstream does that, the > distribution has to make a choice between bleeding-edge code and hurting > its users. The code will still be there for the next release - and maybe > by then it will have fixed its backwards compatibility. I have never seen an upsteram breaking ABI reverting to a previous soname because ABI unbreaking happening later. In libdap there are frequent API/ABI breaking but I have no choice other than accepting these changes (between fedora releases) because dependent software always use the latest API. -- Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
