On Tue, Sep 05, 2017 at 08:57:24AM -0500, Carlos O'Donell wrote: > On 09/04/2017 07:31 AM, Petr Pisar wrote: > > 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. > Fine. > > 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? > In other words no new features because the interface packages will remain the GA packages (minus bug fixes on exception policy). Does it mean that when a need for a new feature arises, e.g. adding getrandom(3) into glibc <https://bugzilla.redhat.com/show_bug.cgi?id=1329996> we will produce a new platform stream distinct from the GA stream? -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
