Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

Zentino · 2025-04-27 04:00:11

`ntfsprogs-ntfs3` is a package for NTFS filesystem utilities from NTFS-3G project, without the ntfs-3g driver itself. Recently this package was deleted due to [PRQ#71567]:

matthewq337 wrote:

linux-lts is 6.12 now. No reason to backport for <=5.17 .

However, the package has no relation with backporting ntfs3 to old kernels. Unneeded packages is `ntfs3-dkms` .

The actual reason the deletion request was accepted is that the package is a duplicate to `ntfs-3g` . However I don't agree with this, AFAIK the package build only NTFS filesystem utilities but not the driver. It does be different configuration set of ntfs-3g but the purpose is to remove driver, so in my opinion it should not be regarded as a duplicate.

BTW I keep 2 reason that the package is useful personally:
1. Make use of the bundled mount.ntfs script so I can mount a ntfs partition by ntfs3 with no arguments.
2. I don't want NTFS-3G FUSE driver in my system.

Since Paragon have not release free NTFS filesystem utilities yet (also seems no plan in the future), `ntfsprogs` is the only alternative (I know ntfs-3g provides this).

Please vote whether the package should be kept or not. Detailed reason welcomed.

Zentino · 2025-04-27 04:20:33

@Hanabishi @nl6720 I'm really curious about your thoughts. Please let me know your opinions.

seth · 2025-04-27 05:34:26

package is a duplicate to ntfs-3g … I don't agree … use of the bundled mount.ntfs script … I don't want NTFS-3G FUSE driver in my system

Leaving aside the obvious "why don't you want the driver"
1. just keep the "mount.ntfs script" locally, except that's not a script tbw.
2. https://man.archlinux.org/man/core/pacm … en#OPTIONS - NoExtract, nb. that the /usr/bin/mount.ntfs "script" links /usr/lib/libntfs-3g.so.89

So assuming you want to keep the other handy ntfs tools, the only stuff you'd actually block would be
* usr/bin/lowntfs-3g
* usr/bin/mount.lowntfs-3g
* usr/bin/mount.ntfs-3g
* usr/bin/ntfs-3g
* usr/bin/ntfs-3g.probe
which, yeah, would be something you'd have done and achieved… what?

If you're putting up w/ ntfs anyway, I'd keep all drivers around anyway - just in case.

Zentino · 2025-04-27 07:26:47

Tks @seth, I learned this new way to block package stuff with NoExtract. But there are several confusions.
1. Keep custom mount.ntfs script out of package manager with NoExtract. It's a little tricky because if forgotten you would receive errors from Pacman.
2. If I block too many files from ntfs-3g, the applied files could not be considered a duplicate to original package, which justify another package being kept.

Also, too much modifications on packages is opposite to the main purpose of package managers. They make inconsistency between different installations, leading to hard debugging process in system maintenance. This is unacceptable thing as partial upgrade.

oech3 · 2025-04-27 09:41:48

ntfs-3g has mount.ntfs and mount.ntfs-3g symlinks to /usr/bin/ntfs-3g.
So I cannot use mount -tntfs3 for daily use if we lose ntfsprogs-ntfs3 without editing ntfs-3g package even I agreed with installing fuse drivers.
/usr/bin/mount.ntfs3 or ${PATH}/mount.ntfs is not recognized by mount command.

Last edited by oech3 (2025-04-27 09:42:45)

oech3 · 2025-04-27 09:46:58

Last comment of https://github.com/util-linux/util-linux/issues/1508 suggests a solution by kernel config for my comment.

Muflone · 2025-04-27 09:52:53

AUR is not a place where to keep your personal preferences about any files you don't want in your system.

ntfsprogs-ntfs3 a duplicated package for ntfs-3g, it simply removes some files from the same package.

Whatever your reason for not having a file provided by the author are, this doesn't change in any way this package is duplicate and it shouldn't be uploaded at all.

Most importantly it shouldn't be uploaded again after the first deletion.

Even more importantly it MUST NOT be uploaded once more after it was deleted for the 2nd time, entirely ignoring the PM decision.

I know the two previous uploads were not made by Zentino so I'm trying hard to communicate him to never upload packages previously deleted if the deletion reasons are not solved.

Of course PMs can be wrong sometimes but you first discuss the mistake with the PM or within aur-request or aur-general list, then later if the mistake is clear and acknowledged by PM, you can re-upload the package deleted by mistake.

This hasn't happened in both previous uploads. The package will be deleted for the third time but a fourth upload from the same uploaders will lead to AUR account suspension.

Muflone · 2025-04-27 09:57:32

oech3 wrote:

ntfs-3g has mount.ntfs and mount.ntfs-3g symlinks to /usr/bin/ntfs-3g.
So I cannot use mount -tntfs3 for daily use if we lose ntfsprogs-ntfs3 without editing ntfs-3g package even I agreed with installing fuse drivers.
/usr/bin/mount.ntfs3 or ${PATH}/mount.ntfs is not recognized by mount command.

This is something to discuss with the ntfs-3g maintainer and it may worth a bug to try to enhance the current situation.

Duplicated packages on AUR are not allowed.

seth · 2025-04-27 10:10:42

You can substitute the symlink for the script ntfsprogs-ntfs3 actually uses, https://aur.archlinux.org/cgit/aur.git/ … rogs-ntfs3

#! /bin/sh

# mount.ntfs : catch {,-tauto,-tntfs} NTFS mounts
# ===============================================
# (c) DLCB 2/11-2021

exec mount -tntfs3 "$@"

and NoExtract the files from ntfs-3g you don't want for various reasons.
I'm not sure how to forget that, but pacman.conf allows you to "Include = " a speaking filename.

oech3 · 2025-04-27 10:14:52

@Muflone Thankyou for replying. I'l try. I consider the situation that packagers do not need to do something wrong is better than correct wrong things.

Last edited by oech3 (2025-04-27 10:15:08)

Hanabishi · 2025-04-27 10:54:06

Zentino wrote:

@Hanabishi @nl6720 I'm really curious about your thoughts. Please let me know your opinions.

Well, despite it could be useful, it's against the rules. Simply tweaking build options is not considered enough for not being a duplicate.
Fairly speaking, you probably only need the tools occasionally. So it's not a big deal to install ntfs-3g, do the thing, and then uninstall it.

And actually I see more reason in splitting official ntfs-3g package instead. You could make a request for that on the bugtracker.

oech3 · 2025-04-27 10:59:55

Is submitting a pacman hook to override /usr/bin/mount.ntfs allowed until mount.ntfs was removed from ntfs-3g? It does not provide subset of ntfs-3g.

I wonder that subset package is duplicated package.

seth · 2025-04-27 11:31:03

Pointing out the rather obvious: nothing prevents you from using a local PKGBUILD and building your own ntfs-3g variation.

The main question is, whether addressing any of this is of public interest¹ - and

seth wrote:

If you're putting up w/ ntfs anyway, I'd keep all drivers around anyway - just in case.

why having the 3g driver around as an option is a problem at all.

This is unacceptable thing as partial upgrade.

No. Partial updates aren't even "unacceptable", they'll just systematically run you into trouble.
Removing some leaf-binary will not. People NoExtract i18n and documentation all the time, maybe even headers.

Also, too much modifications on packages is opposite to the main purpose of package managers.

You're not "modifying" anything but skip some files and even iff: users install ffmpeg-whatever from the AUR, forget about it and show up asking "why does mpv crash" - using AUR packages instead of local packages doesn't change anything about that problem, using NoExtract instead of local packages stripping files doesn't change anything about that problem.

¹ The only reason I see why the AUR vector might remotely relevant is spelled "yay" - and you could use a local repo to make that happy.
I still don't get the abhorrent problem ntfs-3g poses, you're using NTFS - it's not getting much worse than that.

Hanabishi · 2025-04-27 11:49:28

seth wrote:

Pointing out the rather obvious: nothing prevents you from using a local PKGBUILD and building your own ntfs-3g variation.

Yeah, that's also an option. I personally do that with many official packages. Just add them into IgnorePkg list, or assign some custom group to them inside PKGBUILDs and use IgnoreGroup.

seth wrote:

why having the 3g driver around as an option is a problem at all.

I guess because it tries to push itself as a primary driver. Also pulls in extra dependencies.

seth wrote:

I still don't get the abhorrent problem ntfs-3g poses, you're using NTFS - it's not getting much worse than that.

It is much worse.
1. Doesn't support some exotic NTFS features and some are poorly implemented.
2. Like 10x slower than the kernel one. https://openbenchmarking.org/result/200 … TFSCOMPA56

oech3 · 2025-04-27 11:51:04

seth wrote:

why having the 3g driver around as an option is a problem at all.

This reason is coming from hypervigilance. But fuse2 required by ntfs-3g have fusermount SUID binary.

seth · 2025-04-27 12:34:00

I guess because it tries to push itself as a primary driver.

Nope, udisks defaults to ntfs3 and the rest is a matter of your fstab?
How and where exactly does ntfs-3g force itself upon you?
I'd suggest to fix that, not trying to make it fail.

fuse2 and even more fuse3 are hard dependencies by a lot of things, you might rather want to NoExtract those binaries then?
And obviously

a pacman hook to override /usr/bin/mount.ntfs

won't do much about that.

Hanabishi · 2025-04-27 12:44:49

seth wrote:

How and where exactly does ntfs-3g force itself upon you?

If you don't explicitly specify '-t ntfs3' in the mount command, NTFS-3G takes precedence.
Although, that probably would be addressed in the package itself.

seth · 2025-04-27 13:58:42

Ok, but oc you've to specify the mount option if you're not installing ntfs-3g at all as well.
Basically you just want the script from #9 and NoExtract the mount helpers from ntfs-3g
Controlling the mount helper might be grounds for a split ntfs-3g package (notably should util-linux ever gain immediate ntfs3 support)

Hanabishi · 2025-04-27 14:03:59

seth wrote:

Controlling the mount helper might be grounds for a split ntfs-3g package (notably should util-linux ever gain immediate ntfs3 support)

Turns out it has the support for it. We just need to enable this kernel option.

Zentino · 2025-04-27 14:31:27

Thank you all guys for the discussion. It inspired me a lot. I see why the package is considered a duplicate. Now I have no argument with deletion of the package.

@Muflone sorry again for disturbing you with this upload. I just misunderstood the reason at first. I would not have pushed into git if I knew it was deleted because of duplication rules. Next time I will ensure a contact or a clear discussion be made first of all.

BTW, it should be better if AUR request is showing the discussion process more clearly in the mailing list. I'm not to blame but I didn't get enough information about the acceptation of the delete request.

oech3 · 2025-04-27 15:39:54

By the way, does anyone know about progress about userspace tools by Paragon talked in https://www.paragon-software.com/home/ntfs3-driver-faq/ ?

HurricanePootis · 2025-04-27 23:15:55

I've created a merge request here to create an ntfsprogs-ntfs3 split package officially upstream.

oech3 · 2025-04-28 07:17:12

@Muflone We lost the way to search AUR packages depending on ntfs-3g before @HurricanePootis 's MR is merged since ntfsprogs-ntfs3 was removed. Renaming ntfs-3g will break them. How to search them and contact with maintainers?

Muflone · 2025-04-28 07:52:24

AFAIK there's not such feature to search AUR packages depending on official packages

Lone_Wolf · 2025-04-28 10:40:00

Correct, but the Aurweb RPC interface can help to find aur packages that depend on a package .

https://aur.archlinux.org/rpc/v5/search/ntfs-3g?by=depends

currently shows 21 aur packages that depend on ntfs-3g .

Arch Linux

#1 2025-04-27 04:00:11

Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#2 2025-04-27 04:20:33

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#3 2025-04-27 05:34:26

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#4 2025-04-27 07:26:47

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#5 2025-04-27 09:41:48

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#6 2025-04-27 09:46:58

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#7 2025-04-27 09:52:53

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#8 2025-04-27 09:57:32

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#9 2025-04-27 10:10:42

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#10 2025-04-27 10:14:52

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#11 2025-04-27 10:54:06

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#12 2025-04-27 10:59:55

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#13 2025-04-27 11:31:03

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#14 2025-04-27 11:49:28

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#15 2025-04-27 11:51:04

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#16 2025-04-27 12:34:00

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#17 2025-04-27 12:44:49

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#18 2025-04-27 13:58:42

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#19 2025-04-27 14:03:59

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#20 2025-04-27 14:31:27

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#21 2025-04-27 15:39:54

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#22 2025-04-27 23:15:55

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#23 2025-04-28 07:17:12

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#24 2025-04-28 07:52:24

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

#25 2025-04-28 10:40:00

Re: Should we keep package `ntfsprogs-ntfs3` or it is just a duplicate

Board footer