On 09/06/2017 03:50 AM, Petr Pisar wrote: > On 2017-09-06, Petr Pisar <ppisar@xxxxxxxxxx> wrote: >> 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? >> > I will answer to myself: Yes, we will because modules should be fully > compatible inside one stream to allow users to downgrade to a previous > stream release (e.g. in case of a regression). Correct. In traditional Fedora the glibc release only adds new symbols during GA. The GA process is an event which we use to add new symbols, and then freeze the API/ABI. Therefore you can move between installed glibc versions in a given Fedora GA without loosing compatibility. In a modular world I believe this equates to a stream of the platform module. I expect that at every glibc upstream release we will probably want to create a new platform stream with the new glibc symbols. This would also provide a new platform-glibc to use for linking against to get the new symbols, but we wouldn't have to do that if we didn't want to. Other modules will then move to the newer platform stream when they are ready, but once on that newer stream, with a newer platform-glibc, you can't go back. However, your stream that keeps providing platform-glibc, can actually move glibc forward to any version it wants since platform-glibc prevents you from using any of the new functionality. So we could deploy performance improvements without deploying new features. So you could stay on the older platform, with an older platform-glibc, but a newer glibc if needed. > This is not something we support in classical Fedora (because we do not > retain previous releases in repositories. Will we support it in modular > Fedora?). It was always my opinion that *if* Fedora's content delivery network retained old versions of glibc, then you *could* downgrade to them within the range of versions associated with your Fedora release. For example you could pick any number of the glibc releases that came out for F26 on a given F26 install. With the split I'm suggesting for interface/implementation you could move your installed glibc to any release you want that is no older than the platform-glibc package used to build all of your installed packages. Does that answer your questions? -- Cheers, Carlos. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
