sysutils/fusefs-ntfs: Update to 2021.8.22 Remove everything, re-adding only what is necessary to pass build/package.
Details
- Reviewers
danfe
- currently passes poudriere on 13amd64
- additional testing/updates required
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
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. |
This patch no longer applies, due to ports change f3c7a7686768351238894670b203c28526d247c1 .
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 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. |
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'.
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.