On 09/04/2017 07:31 AM, Petr Pisar wrote: > On 2017-09-01, Carlos O'Donell <carlos@xxxxxxxxxx> wrote: >> I've written up some of the key ideas here: >> https://fedoraproject.org/wiki/BaseRuntimeInterface >> >> Any feedback would be appreciated, including bikeshed on component >> name prefix for frozen interface pakcages e.g. base-*. Thank you for your feedback! > What if there is a bug in the behavior of the frozen base-* packages? Do > we have to live with the bug for the rest of the life time of the base > (=platform)? Or do we break this rule and replace the broken package > with a patched one? We get this question a lot in glibc. There is a natural tension to want to break the API/ABI in a stable release to fix a bug that is known. In general we live by an "exceptions based policy" which is to say that we follow the stable API/ABI rules very strictly, but the community can be convinced to grant an exception. I think if the platform module releases with a base-glibc package (defines the interface to build against) that has a bug, say it has the wrong ABI for a given function, then you need to look at the specifics of the failure to decide if base-glibc should be fixed and rebuilt. I added a Q&A question about this. Please tell me if that answers your question. > If the second one is the answer, do we know how it will affect packages > whose build script does run-time checks (i.e. every ./configure script) > to tune compile-time options? It depends on how each package implements the split of interface/implementation. > More strictly speaking, will we be adding new features into the same stream of > the base module? I guess we won't. Otherwise we have to update the > frozen base-* packages accordingly to make the new features available at > build-time of packages that want to use the new features. The interface base-* or platform-* (whatever we call them) packages would remain frozen for the lifetime of say the platform modules specific major version. However, we could rebase the implementation package without specifically impacting the existing components. In the case of glibc, because we alter the linker path, package configure checks will only ever see the interface glibc provided by the platform-glibc package. At present the platform-glibc is a full glibc which can run in the system. If we were to trim platform-glibc into just some stripped DSOs then we might run into configure check problems. We would have to make all such configure checks be cross-compile safe, which is not something I'm going to target at this stage, but it would be an interesting project to consider. Does that answer your question? I added another Q&A item for this. -- Cheers, Carlos. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
