Page MenuHomeFreeBSD

[WIP] sysutils/fusefs-ntfs: Update to 2021.8.22
Needs RevisionPublic

Authored by koobs on Jan 28 2022, 12:04 PM.

Details

Reviewers
danfe
Summary
sysutils/fusefs-ntfs: Update to 2021.8.22

Remove everything, re-adding only what is
necessary to pass build/package.
Test Plan
  • currently passes poudriere on 13amd64
  • additional testing/updates required

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

koobs retitled this revision from Summary: sysutils/fusefs-ntfs: Update to 2021.8.22 to [WIP] sysutils/fusefs-ntfs: Update to 2021.8.22.Jan 28 2022, 12:09 PM
koobs edited the summary of this revision. (Show Details)

Refresh patch after git rm files, diff against origin/main

asomers added inline comments.
sysutils/fusefs-ntfs/Makefile
33

Did you mean to leave this line here, and lines 36-37 ?

sysutils/fusefs-ntfs/Makefile
33

Yeh, just for now, this patch is not in final form ready for tree. I'm at the 'disable all the things' and establish a baseline upstream stage.

danfe requested changes to this revision.May 26 2022, 4:44 AM
danfe added a subscriber: danfe.

This proposed update is botched. You've removed most of the existing work for no reason. You've also removed all the patches, particularly, patch-libntfs-3g__unix_io.c and thus broke NTFS mounting for me:

ntfs_attr_pread_i: ntfs_pread failed: Invalid argument
Failed to read NTFS $Bitmap: Invalid argument
Failed to read NTFS $Bitmap: Invalid argument
The device '/dev/ada0s1' doesn't seem to have a valid NTFS.

Please do not make changes to the port while we're investigating known issues with it, as version 2021.8.22 exhibits them as well.

sysutils/fusefs-ntfs/Makefile
23

There's nothing wrong with multiple arguments per line for the CONFIGURE_ARGS, but even if you prefer tall (one argument per line) version for some reason, it should not be part of the version bump or other function change.

25

What happened to the options block? They equally apply to the new version just as they do to the current one.

33

I'm at the 'disable all the things' and establish a baseline upstream stage.

I don't understand this rationale, as well as removing most of the existing port's Makefile. Simply bumping the PORTVERSION is enough for the port to build (modulo adjusting the checksum, one patch, and pkg-plist). Throwing away previous work, mixing style and functional changes is not how we do things in FreeBSD, sorry.

sysutils/fusefs-ntfs/pkg-plist
1

Directories are typically listed at the end of the packaging list (as as it is right now).

27

Why? It was properly sorted before.

This revision now requires changes to proceed.May 26 2022, 4:44 AM

Alexey, This diff is not not a ports commit proposal, as should be clear from the diff summary (WIP) and description:

Remove everything, re-adding only what is
necessary to pass build/package.

They also explain the followup I'm at the 'disable all the things' and establish a baseline upstream stage.

The problem with this port has always been no-one maintaining it because no-one has any idea if/how it worked, and no-one (clearly) wanted to touch it. It the meantime we fell behind upstream for 5+ years.

A clean baseline is a perfectly reasonable initial attempt to clear a path through the mess, even if that's not necessarily obvious/clear to people.

Lastly, please dial down the rhetoric when communicating, its really off putting. In particular, focus on the code, not the people involved. A really great way to do this is to avoid the use of 'you'.

@koobs wrote:

Alexey, This diff is not not a ports commit proposal, as should be clear from the diff summary (WIP) and description:

Remove everything, re-adding only what is necessary to pass build/package.

A clean baseline is a perfectly reasonable initial attempt to clear a path through the mess, even if that's not necessarily obvious/clear to people.

It might seem reasonable and perhaps easier path to follow, but if we all had to start from scratch every time we had to deal with a new version or accumulated technical debt, there won't be nearly as much software we can enjoy today. :-)

The problem with this port has always been no-one maintaining it because no-one has any idea if/how it worked

Yeah, reading through its commit history over the last couple of days, I've noticed that.

and no-one (clearly) wanted to touch it.

Well, so I did. It was not really that scary and took just a few hours to untangle some knots.

In the meantime we fell behind upstream for 5+ years.

I reckon we had caught up now. Last night I had to push the latest security update (admittedly, after rather mild testing) to address eight critical CVEs. I will be keeping my hand on its pulse until, at least, we squish all our open PRs, so please ping me if you find any problem with the port and I'll try to address it promptly.