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

Re: [Cluster-devel] mount.gfs2 obsolete upstream (scheduled to be removed)

On 08/10/2011 03:26 PM, Steven Whitehouse wrote:
> Hi,
> On Wed, 2011-08-10 at 14:43 +0200, Fabio M. Di Nitto wrote:
>> On 08/10/2011 02:16 PM, Steven Whitehouse wrote:
>>> Hi,
>>> Just a reminder that when Fedora 14 is no longer being updated, we
>>> intend to remove mount.gfs2 from the upstream gfs2-utils source. There
>>> should be no user visible changes beyond the removal of the utility when
>>> this happens as kernels and gfs2_controld have been able to use the new
>>> system for mounting for some time.
>>> So this is just a heads up so that it isn't too much of a surprise when
>>> it happens in a few months time.
>>> Also scheduled for removal are gfs2_quota and gfs2_tool. Both of these
>>> will be removed shortly after Fedora 17 is released. They are both
>>> considered obsolete and alternatives have been available for some time.
>>> In the case of gfs2_quota, that means the generic quota package that is
>>> supplied with Fedora. In the case of gfs2_tool, that means tunegfs2 or
>>> mount options, depending on which feature is required.
>>> If there are any questions, please let us know,
>>> Steve.
>> It might be a good idea to lay down a map of upstream versions required
>> to drop mount.gfs2 and quota.
>> New gfs2-utils without mount.gfs2 requires kernel > x.y.z and
>> gfs_controld > a.b.c. (we ship gfs_controld from gfs2-utils, but people
>> might still have old versions around... just in case)
> Yes, it was a long time ago, so I'll try and dig out the version. Any
> 2.6.3x kernel or newer should be ok though I think.
>> similar for quota support.. is a new quota-tools version required?
>> kernel? etc.
> For certain operations a newer quota package is required, and there
> needs to be a kernel with the XFS-style quota interface. Both have been
> around for a while, and I'll also try and dig those details out nearer
> the time.

Right that's exactly the kind of info I am talking about kernel > foo +
CONFIG_BAR set etc.

> The docs have all been updated to reflect the new way of doing things,
> and there have been a number of previously posted reminders of this too,
> so it shouldn't be too much of a surprise.

No it's generally not a surprise for people/users that read docs :)

The users I am trying to protect are:

1) packagers in distributions != Fedora
2) people that builds backports of our packages on RHEL5 or Centos 5 or

It might also be an option to extend gfs2-utils configure.ac to check
for those versions at build time. It might be an excessive precaution,
but it could also save some headaches.. no strong opinion here.. barely
a suggestion.


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