Add ac_cv_sys_long_files_names=yes to configure cache

[marino]

Summary

I know of at least three ports that have the same long file names
support check during GNU configure

lang/expect
devel/patch
devel/ncurses

There are likely more. The problem is that this check is invasive; it
touches ${LOCALBASE}/lib, affect the modification time of the directory.
All BSD filesystems support long file names, so caching "yes" for this
check solves the file system violations during the configure stage.

Note 1: If approved, local setting in devel/ncurses will be removed
Note 2: Templates/config.site has "appearred" mispelling three times

(lines 233 - 237) but is not fixed in patch as it is unrelated.

[mat]

It only touches that place if you build as root, which is not the default in poudriere, so there's no real need. But, well, YMMV.

[marino]

Building as root is a legitimate thing to do.
Morever, it probably attempts to use /usr/local/lib as a user, but it just fails and moves to the next location. I think there are a few patches in a list that it can try.

In any case, I am not aware of any FreeBSD configuration that doesn't support long file names.

[mat]

In D6160#131140, @marino wrote:

Building as root is a legitimate thing to do.

Well, no, doing something as root is not something legitimate to do. There is no port that does not build as a regular user. Build tools that do it should be fixed to not do it.

[marino]

That is an absurd take on this.

A) Is it possible to build ports as root user? Answer: yes

2. Is it permissible that the port write to /usr/local during the configure phase or build phase? answer: no, it is not allowed
3. If the port does this, does it have to be fixed to not do it? Answer, yes it does

Thus, there's no further discussion to be had here. I don't want to hear an opinion that nobody should use the root user to build ports. It's a legitimate thing to do, regardless if you personally think one should do it or not.

These ports are violating the rule of not touching localbase during specific phases. It can be fixed globally or indvidually. I have proposed a global and non-invasive fix for this problem. (There should not be a debate on whether this is a problem or not, writing to localbase is a problem).

[marino]

(to be pedantic, there are some directories in /usr/local that are permissible to write, e.g. /usr/local/var but I was referring to big ones like /usr/local/bin, /usr/local/lib, etc)

[bapt]

In D6160#131139, @mat wrote:

It only touches that place if you build as root, which is not the default in poudriere, so there's no real need. But, well, YMMV.

so it is still an important issue to fix

[bapt]

In D6160#131429, @mat wrote:

In D6160#131140, @marino wrote:

Building as root is a legitimate thing to do.

Well, no, doing something as root is not something legitimate to do. There is no port that does not build as a regular user. Build tools that do it should be fixed to not do it.

Which does not prevent people from building as root anyway :(. Even if you want to push them into building as a regular user, you first need to let time for people to change their way of building (building as a regular user is really supported since recently and the default install of ports does not allow that out of box - the ports tarfile is extracting everything in /usr/ports as root and the default packages, distfiles directory are in there) second most tools portmaser/portupgrade/synth(?) still wildly used are building as root

It is here an easy fix, let's not prevent us from having it :)

[bdrewery]

There's little harm to enabling these as long as it doesn't break anything.

[marino]

Thanks. I just discovered tonight that editors/emacs-devel also has this issue (which means editors/emacs probably has it too).

I'll push the fix. I believe it will not break anything at all.

[marino]

The autoclose feature didn't work when this was committed.
Closing it manually.

[mat]

In D6160#133196, @marino wrote:

The autoclose feature didn't work when this was committed.
Closing it manually.

Mmm, yes, you changed the order of lines in the commit template. The diff revision line has to be the last one for this to work.

[marino]

No, I did not.

This is the ONE commit that I used without a prewritten message specifically so I would use the template. I used the template *exactly* how it was presented to me on FreeBSD 9. something.

The whole thing is just incredibly fragile. It really should be made more robust. While is the order even significant?

[mat]

In D6160#133204, @marino wrote:

No, I did not.

This is the ONE commit that I used without a prewritten message specifically so I would use the template. I used the template *exactly* how it was presented to me on FreeBSD 9. something.

The whole thing is just incredibly fragile. It really should be made more robust. While is the order even significant?

Well, if you did not, then you have a patched ports tree.

The patch has the "Differential Revision" line just before the comment line. It has to be the last one, it's how phabricator works.

Also, really, like always, I'm kindly telling you what you did was somehow wrong, taking time to help you, and you're yelling at me, it really is getting annoying.

[marino]

No, it's a stock tree.
It's fine that you are helping, but you just stated as a fact that I did something wrong, which I absolutely did not do. If you think it's getting annoying to have somebody have to deny accusations, think about how annoying it is to be accused wrongfully.

The larger issue here is that only phabricator has an "order requirement". None of the other tools that scan emails have this limitation. It really should be improved because the requirements doesn't make much sense, nor should people be required to use templates, especially when apparently it's possible that the template doesn't even work right.

[marino]

(to be clear, the order was "wrong", but that's because the template was in that order, so I was wrong to trust the template and not just realize the template was giving me bad direction). So I guess technically I am wrong, but not for the reason you assumed.

[marino]

do we report infrastructure issues with phabricator on bugzilla? If so, I would be happy to open a bug report (that has 70% chance of being ignored) to request that the order requirement be removed.