Add new category fs for file systems

[clausecker]

This patch set adds a new category fs for file systems and file system utilities. The new category is populated with some 126 ports (that's more than x11-clocks!) that look like they might be file-system related.

I was motivated to add this new category when I noticed that many FUSE file systems were shipped as ports named sysutils/fusefs-$foo, making sysutils/fusefs- a pseudo-category for FUSE filesystems. If that's the (anti) pattern, why not make it offical and add a true category for file system ports? Turns out there are a lot more than one might think.

I hope that with this move, we can reduce the load on devel and sysutils (the two most popular misspellings of misc) and make file-system related ports easier to find.

If accepted, this'll be the first new physical category since c5978f0 of 2007-05-19 to be added.

For a full list of affected ports, see the list of commits attached to this PR. If you would like to not have your port moved to fs, please comment or send me an email.

Note that this PR is still wip and will be reviewed, exp-ran, etc. before being committed.

[metalefty]

I personally like that idea. That sounds reasonable because there are more ports than x11-clocks. BTW, I like filesystem(s) more than fs.

[rosorio]

Hi',El 30 sept 2024 2:30, metalefty ***@***.***> escribió: I personally like that idea. That sounds reasonable because there are more ports than x11-clocks. BTW, I like filesystem(s) more than fs.Same opinion  +1Rodrigo —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[yurivict]

+1 I like this idea too.

[Jehops]

Robert, as we discussed in Dublin, I generally think creating a new fs category for filesystems is a good idea. However, I'm on the fence about moving utilities such as sysutils/zrepl or sysutils/zfs-snapshot-mgmt. If others agree that also moving those ports is beneficial, then we should make it clear in the comment in fs/Makefile that utilities related to filesystems also belong there.

Here are a few more for you:

commit 230cb49ccce5a79985875ad16e36da0b8f9e8c52
Author:     Emanuel Haupt <ehaupt@FreeBSD.org>
AuthorDate: 2024-10-02 07:52:13 +0000
Commit:     Emanuel Haupt <ehaupt@FreeBSD.org>
CommitDate: 2024-10-02 07:52:32 +0000

    sysutils/fusefs-mergerfs: Add new port
    
    mergerfs is a union filesystem geared towards simplifying storage and
    management of files across numerous commodity storage devices. It is
    similar to mhddfs, unionfs, and aufs.

2. (If we decide fs utilities should also be moved)

% cat sysutils/zap/pkg-descr
Maintain and replicate ZFS snapshots

zap automates the management of zfs snapshots.  With a few, simple
crontab entries, it can be used to create a comprehensive zfs backup
system.  There are no configuration files.  All parameters are supplied
on the command line or in zfs properties and all snapshot information
is stored in snapshot names.

zap plays nice with manually created snapshots or snapshots from other
tools.  It will only operate on snapshots it creates.

[clausecker]

@Jehops Thank you for your concerns.

The current comment was supposed to read:

COMMENT = File systems and utilities

but I must have dropped the second half during copy editing. I'll restore that in my next push. I am open to having a category for only file system drivers, but I would prefer to also put the fs utilities in there. We could also add two categories: one for file system drivers and one for associated utilities (e.g. fsutil or fs-mgmt).

I'll go add the other two ports, too.

[Jehops]

COMMENT = File systems and utilities

Taking inspiration from existing comments, how about File systems and related utilities?

games/Makefile    COMMENT = Games and related software
databases/Makefile    COMMENT = Databases and related software
finance/Makefile    COMMENT = Monetary, financial, and related applications

[clausecker]

@Jehops Yeah sure, works for me. I'll put that in with my next edit.

[diizzyy]

Why this is submitted to GitHub? It's not a supported way of submitting patches (see Porters Handbook). Submit it to bugzilla and continue the discussion there.

[clausecker]

@Diizzy We do process pull requests against ports.

I have submitted this change set like this as it's much easier to review the 137 individual ports affected than it would be with a big patch on Phabricator or Bugzilla.

[bsdimp]

@diizzyy Other than "the rules" is there some good reason not do it here? It seems to have generated a reasonable amount of feedback so far.

[diizzyy]

@bsdimp A lot more eyes and participants on bugzilla (and indirectly mailing lists), there's little to no involvement/interraction with most of the community including committers etc on GitHub.

[bsdimp]

@diizzyy And bugzilla is the worst tool ever to review changes (even worse than phabricator). It's barely adequate as a conveyer belt for submissions. Github is much better, and can as easily be references in other forum as bugzilla. The current bugzilla workflow is unustainable, imho, and requires too much extra work. fuz's changes likely need detailed commentary, for which bugzilla is ill suited to do on a change this large. It can't handle 10 commits in one go, let alone 140. Since it is an imperfect fit, fuz will also need to seek review elsewhere (which I thought I'd seen an email go by that did), true, but going to bugzilla is setting him up to fail because it would be such a bad tool for a change like this.

[yurivict]

And bugzilla is the worst tool ever to review changes [...]

This is off-topic here, but you probably have never seen Jira that is used by many companies.
Compared to Jira, Bugzilla is a totally sane and pleasant tool.

---

The key to your submission is not the exact list of ports, but the portmgr approval.
You need to contact somebody in the portmgr team and ask for approval.

Here is my proposal for the physics and chemistry categories from 2018 which is still not approved: https://reviews.freebsd.org/D13481

The FreeBSD Portmgr is a bit slow, don't you think?

[clausecker]

@yurivict My original email went to ports@ as well as portmgr@ and explicitly asked for approval. I hope that suffices. If not, I'll bug portmgr some more (I encourage you to do the same about your proposal).

[diizzyy]

@bsdimp
Your personal preferrence is another topic as Yuri pointed out. The main issue is that this isn't a supported way of doing submissions, notifying people etc.

[bsdimp]

@bsdimp Your personal preferrence is another topic as Yuri pointed out. The main issue is that this isn't a supported way of doing submissions, notifying people etc.

Yes. And that's a problem too. The ossified FreeBSD processes aren't helpung the project.

[clausecker]

I have just requesed an exp-run on Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281988

[mat813]

Please rename the category from fs to filesystems

[clausecker]

@mat813 That's really quite a mouthful. Should we also rename sysutils to system-utilities? Or devel to development? I would like to avoid such a long category name. FS is a well known and unambiguous acronym, so I think it's fine as a category name.

[diizzyy]

As much as fs is likely to be obvious for advanced users using really short acronyms can also cause unnecessary confusion.
OpenWrt for example also uses the full name, https://github.com/openwrt/packages/blob/master/utils/exfatprogs/Makefile#L24

[dlangille]

I too prefer filesystems over fs.

EDIT: I've changed my mind, given the project is already using fs for the filesystem mailing list.

[Jehops]

I argue that using fs to describe the category follows precedence more than filesystems.

The closest word to file systems in an existing category is windows managers, and we use wm for that category. Using fs to describe a file system is so common it's in the first sentence of the File Systems Wikipedia page.

[dlangille]

I argue that using fs to describe the category follows precedence more than filesystems.

The closest word to file systems in an existing category is windows managers, and we use wm for that category. Using fs to describe a file system is so common it's in the first sentence of the File Systems Wikipedia page.

I concede.

EDIT: we have a mailing list: fs[@]freebsd[.]org - https://lists.freebsd.org/archives/freebsd-fs/

[clausecker]

@mat813 @Jehops @dlangille So, what do we do about this one? Typing out filesystems makes me sad...

[mat813]

Please name the category filesystems.

[clausecker]

Rebased onto ab6304e.

[mat813]

Can you request an exp-run so we make sure everything is squared away, and if it comes back without problems and nothing new comes up here, feel free to commit it.

[mat813]

Oh, before you land this, please squash it all into a single commit.

[clausecker]

@mat813 Are you sure? I specifically made it a bunch of individual commits so it's easy to move individual ports back if desired. Note that each of the commits is self-contained.

[mat813]

Please squash it all.
Also, make sure the tree is not broken with running at least make index.

[clausecker]

@mat813 I have verified that make index is fine, as is a poudriere bulk -an dry-run (which should pick up any dangling dependencies).

[clausecker]

Updated to just one squashed commit as requested.

Note that I'll likely have to rebase the patch set again before landing it, and that's much easier to do on the non-squashed patch set, so when landing, I will first rebase the unsquashed patch set and then squash it again before landing.

[dlangille]

Updated to just one squashed commit as requested.

Note that I'll likely have to rebase the patch set again before landing it, and that's much easier to do on the non-squashed patch set, so when landing, I will first rebase the unsquashed patch set and then squash it again before landing.

Do you have an ETA on landing please?

[clausecker]

@dlangille I plan to land this one the instant I get portmgr approval. There is nothing else left to do.

[rene0]

Approved with portmgr hat on

[clausecker]

Will remove the following two ports from the patch set: funionfs, fusepak. This is because they don't have TIMESTAMP in their distinfo and they don't fetch, so I can't regenerate distinfo. Both are slated for removal, so I guess it's fine.

[clausecker]

Closed by 6e2da96.

[bdrewery]

I'm in a minority here but don't like this kind of moving chairs change.

• Some of us use "meta packages" that have RUN_DEPENDS on specific packages. Poudriere doesn't support MOVED there (no tool does). I'll consider adding support. In the meantime I have to duplicate every port and use .if exists checks.
• Most ports reasonably could have multiple categories. What's a filesystem category that's not a sysutils? My port zfstools fits both. Are we nuking sysutils?
• "src-mgmt" is coming next, again every single tool going into there also fits in "devel", so what benefit is there?
• I don't see the motivation. What benefit does it bring? I used to be able to identity fusefs ports with echo */*fusefs* but now can't with that, so it's back to freshports or git grep anyway.
• POLA used to mean something. This kind of thing and renaming services s/-/_/g just creates downstream problems.
• This is changing decades old naming schemes for what benefit? It only creates mental work.
• Forces rebuilds.

Complainers don't always show up in a PR. This change hasn't even hit quarterly yet.

[grahamperrin]

I'm in a minority here but don't like this kind of moving chairs change.

… Complainers don't always show up in a PR. This change hasn't even hit quarterly yet.

I'm not averse to change, however (in a future ideal world) there should be broader planning – including src (at least, manual pages), not forgetting Bugzilla and FreshPorts (its bug-finder icon) – before move-related commits such as this.

That's an ideal world. I'm not complaining about reality :-)

Thanks

[grahamperrin]

283881 – Update documentation/ and website/ following moves of 142 ports to the filesystems category