Re: iproute package update policy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 14, 2016 at 01:36:38PM +0100, Phil Sutter wrote:
> On Mon, Mar 14, 2016 at 12:21:33PM +0000, James Hogarth wrote:
> > On 14 March 2016 at 11:47, Phil Sutter <psutter@xxxxxxxxxx> wrote:
> > 
> > > Hi,
> > >
> > > So far my idea of maintaining Fedora's iproute package was to do full
> > > version updates only in Rawhide and backport patches selectively to
> > > stable versions on behalf of bug reports.
> > >
> > > But since stable versions indeed receive full kernel updates (not just
> > > backported patches), there is an understandable amount of frustration
> > > amongst users when the shiny new kernel that comes with e.g. F22
> > > provides features userspace does not support.
> > >
> > > Especially since upstream iproute2 does not really have a concept of
> > > stable versions, I'm in a bit of a dilemma here: update to keep in sync
> > > with the kernel or not update to not unnecessarily destabilize the
> > > system?
> > >
> > >
> > >
> > Does a new release change the user facing 'API' in a way that might not be
> > backwards compatible to any existing scripting of the iproute2 suite of
> > commands?
> 
> No, upstream iproute2 is very careful to not break existing scripts.
> Internal communication between iproute2 and kernel is treated equally,
> so a newer iproute2 should never cause problems when used on an older
> kernel (and vice versa, if I'm not mistaken).
> 
> > If existing scripting is still expected to work I'd say carry out version
> > updates as and when the kernel maintenance team update kernel in the
> > distribution.
> 
> While this certainly makes sense, I start to wonder what Fedora's
> understanding of 'stability' really is if it seems to not cover the
> packages (including kernel) it distributes. Does it cover only anything
> else, like e.g. installation routine, default settings or components
> used? Apologies if I'm asking trivial questions here. I'm not a native
> Fedora user and therefore lack experience in these aspects.

Things that were working at release should continue to keep working.
So backwards compatible updates are allowed.

(Backwards compatible means that both inter-package dependencies and
user visible APIs are not changed in an incompatible way. So it's OK
to add some functionality, but it's not OK to remove functionality,
and it's not OK to introduce significant changes which would break
users' scripts or compiled programs. Also big changes to the GUIs
or default settings would be frowned upon.)

Zbyszek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux