Re: nfs-utils library dependency littering - fork nfs-utils for Debian? Re: [patch] mount.nfs: Add support for nfs://-URLs ...

[Chuck Lever <chuck.lever@oracle.com>]

On 12/6/24 12:13 PM, Mark Liam Brown wrote:
> On Fri, Dec 6, 2024 at 5:58 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>> On 12/6/24 11:15 AM, Mark Liam Brown wrote:
>>> On Fri, Dec 6, 2024 at 4:54 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>>>> IMO, using a URL parser library might be better for us in the
>>>> long run (eg, more secure) than adding our own little
>>>> implementation. FedFS used liburiparser.
>>>
>>> Yeah, another library dependency for Debian? First you try to invade
>>> Debian with libxml2 via backdoor, and now you try to add liburlparser?
>>> At that point I would suggest that Debian just forks nfs-utils and
>>> yanks the whole libxml&liburlparser garbage out and replace it with a
>>> simple line parser. Does the same job and doesn't litter Debian
>>
>> This is a political screed rather than a technical concern.
> 
> Nope. Stuffing the libxml2 garbage as dependiy to nfs-utils broke
> dracut in Debian and thus nfsroot support, and that is a REAL WORLD
> technical concern.

You should re-read your initial email. None of this detail is
mentioned there, so it's not unexpected that a recipient might
dismiss your concerns.

Junction support in nfs-utils has always been controlled by the
configure option "--enable-junctions" so that distributions who
cannot or do not want to package libxml2 can build without that
dependency.

There are one or two bugs in this area which prevented this from
working as intended. The intention has always been that distros and
other packagers can choose not to pull in libxml2.


>> For one
>> thing, a fork certainly isn't needed to remove libxml2 or any other
>> library dependency -- all distributors carry local patches to such
>> packages.
> 
> It is a concern that nfs-utils keep adding library dependencies for
> which there is no technical need. Junction support in nfs-utils> could've used a simple tag=value format, instead a slow,
> resource-hungry and upgrade-antagonistic libxml2 was chosen.
> Real world users could not boot after that.

This sounds like a packaging issue; that is, it's specific to the
Debian distribution, not to whether nfs-utils has a new dependency.
It was not a problem for SuSE or Redhat when they enabled junction
support (RH enabled it years and years ago).

Please post a link to bug reports that provide a clear description
of the problem (and preferably also a root cause). This is honestly
the first I've heard of such a problem; and if it truly is an
upstream issue, it should be reported and dealt with here.


> So a fork of nfs-utils would jank out libxml2 and use a plain
> tag=value format for NFS junctions.

It wouldn't be difficult to write a patch series to implement a
KV-based junction format and teach mountd to look for that and the
XML-based one for some transition period. Would you care to give
that a try?


> So nay nay nay to more libraries, or keep it the liburiparser dep off
> by default. People who really want it can do an
> --enable-nfsurlsupportwithliburiparsergarbage.

Why didn't you simply suggest that before?

In fact that is usually the way new features like this one are
introduced to nfs-utils, so it would be a no-brainer if in fact the
maintainer decides to replace the proposed ad hoc URL parser with a
library.


> No one really needs exports and filenames with non-American characters
> anyway, the workaround is just mkdir /myjapanesefiles/, export that
> dir, and keep Japanese file names within that subtree.

You personally might not need to handle non-ASCII characters in your
export paths. However, I'm told that most of the non-Eurocentric world
wants to have support for mounting export paths with non-ASCII
characters directly. So, although the workaround you describe works
today, it's not something that any non-European administrator wants to
use daily.

I have no objection to handling NFS URIs in mount.nfs if no other code
changes are needed. Most other NFS implementations have been able to
deal with them properly for many years.


-- 
Chuck Lever