I see you've had a poll on if you should nuke multiuser code or not.
As somebody who runs a server that is used by multiple people, I simply have to recommend keeping the code.
I played Mines of Moria in highschool. I played the original rogue in college/university. I keep Angband installed on my multi-user servers and recommend people play it.
As such, I would like to point out that the --prefix option is not being honored by the makefile - it's explicitly declared in rules.mk that's included into the makefile itself. Without editing this, the game simply refuses to install as a multi-user platform.
You've no idea how happy I was to find an updated version of angband - and now I'm having to debork things in order to make it work.
It's not a question of "The package maintainer should this" or "The package maintainer should that" - It's a simple question of angband being compatible with the options that sysadmins/sysops/package maintainers/etc simply expect to function because it's a standard - such as --prefix.
There's not really any other game I know of that is not installable in a multi-user environment.
Here's what you should do, by the way things are usually done in my experiance:
First off, most of the people compiling angband are not package admins or sys admins. As such, it will be expected to use /usr/local as the default install path because it's a local-only package. A sysadmin will automatically override this with the --prefix directive, as will a package or distro maintainer - We install it into, say, /tmp/1348nbaliet5/usr/ tree, make sure the contents are layed out like they should be, check permissions, modify things if required, and build the package using /tmp/1348nbaliet5/ as the "base" directory. We then install the package.
Joe User running *nix on a private box will most likely never know, or care, where angband installs to - /usr/local/ is default for this reason. However, it is a de-facto standard that --prefix is supposed to be honored.
I'm currently debating if I should go through the trouble of locating all the hardcoded expectations with the values I *ought* to have been able to override, or if I shouldn't bother and simply use an older version of angband that supports the methodology in which I will use the game - or if I should leave V behind.
This does not make me a happy panda. I've been a sysadmin for more then a decade, and I was a systems operator for multi user machines for more then three years before that.
I'm absolutely more then happy to help out with bugtesting the installation features. However, as much as possible, I want to avoid having to write patches to *regress* multi-user support back into Angband.
Now for my last argument: This is part of Angbands *heritage* you're talking about nuking here. Making it single-user only will not only insure that it doesn't grow, it will provoke alot of people to say "Forget this, I've got 493 users with accounts on this system, I'm busy, and NetHack will give me the installation-set I need."
Please. Don't nuke the multi user environment code. Me & my users use this feature.
As somebody who runs a server that is used by multiple people, I simply have to recommend keeping the code.
I played Mines of Moria in highschool. I played the original rogue in college/university. I keep Angband installed on my multi-user servers and recommend people play it.
As such, I would like to point out that the --prefix option is not being honored by the makefile - it's explicitly declared in rules.mk that's included into the makefile itself. Without editing this, the game simply refuses to install as a multi-user platform.
You've no idea how happy I was to find an updated version of angband - and now I'm having to debork things in order to make it work.
It's not a question of "The package maintainer should this" or "The package maintainer should that" - It's a simple question of angband being compatible with the options that sysadmins/sysops/package maintainers/etc simply expect to function because it's a standard - such as --prefix.
There's not really any other game I know of that is not installable in a multi-user environment.
Here's what you should do, by the way things are usually done in my experiance:
First off, most of the people compiling angband are not package admins or sys admins. As such, it will be expected to use /usr/local as the default install path because it's a local-only package. A sysadmin will automatically override this with the --prefix directive, as will a package or distro maintainer - We install it into, say, /tmp/1348nbaliet5/usr/ tree, make sure the contents are layed out like they should be, check permissions, modify things if required, and build the package using /tmp/1348nbaliet5/ as the "base" directory. We then install the package.
Joe User running *nix on a private box will most likely never know, or care, where angband installs to - /usr/local/ is default for this reason. However, it is a de-facto standard that --prefix is supposed to be honored.
I'm currently debating if I should go through the trouble of locating all the hardcoded expectations with the values I *ought* to have been able to override, or if I shouldn't bother and simply use an older version of angband that supports the methodology in which I will use the game - or if I should leave V behind.
This does not make me a happy panda. I've been a sysadmin for more then a decade, and I was a systems operator for multi user machines for more then three years before that.
I'm absolutely more then happy to help out with bugtesting the installation features. However, as much as possible, I want to avoid having to write patches to *regress* multi-user support back into Angband.
Now for my last argument: This is part of Angbands *heritage* you're talking about nuking here. Making it single-user only will not only insure that it doesn't grow, it will provoke alot of people to say "Forget this, I've got 493 users with accounts on this system, I'm busy, and NetHack will give me the installation-set I need."
Please. Don't nuke the multi user environment code. Me & my users use this feature.
Comment