New port: x11-wm/nscde: modern and functional CDE

[eduardo]

Summary

New port: x11-wm/nscde: modern and functional CDE

- Submitter becomes maintainer

sCDE is a retro but powerful UNIX desktop environment which resembles
CDE look (and partially feel) but with a more powerful and flexible
framework beneath-the-surface, more suited for 21st century unix-like
and Linux systems and user requirements than original CDE.

See also https://github.com/NsCDE/NsCDE

PR:		255929
Approved by:	dbaio, garga (mentors)
Differential Revision:	https://reviews.freebsd.org/D30591

Test Plan

$ portlint -C
WARN: Makefile: Consider adding support for a NLS knob to conditionally disable gettext support.
WARN: Makefile: possible use of absolute pathname "/share/doc/nscde/@g".
WARN: Makefile: possible use of absolute pathname "/share/icons/@g".
WARN: Makefile: possible use of absolute pathname "/libexec/nscde/@g".
WARN: Makefile: possible use of absolute pathname "/sbin/@g".
WARN: Makefile: possible use of absolute pathname "/share/icons/@g".
WARN: Makefile: possible use of absolute pathname "/sbin@g".
WARN: Makefile: possible use of absolute pathname "/libexec/nscde@g".
WARN: Makefile: possible use of absolute pathname "/libexec/nscde/@g".
WARN: Makefile: possible use of absolute pathname "/lib/nscde/@g".
WARN: Makefile: possible use of absolute pathname "/bin/ksh93@".
0 fatal errors and 11 warnings found.

portclippy: OK

portfmt: OK

poudriere testport logs:

140amd64
140i386
130amd64
130i386
122amd64
122i386
114amd64|i386: several qt5 dependencies doens't build on this versions/archs

runtime test: x11-wm works fine

[eduardo]

reformat x11-wm/nscde with portfmt

[dbaio]

There are a lot of patches that changes NSCDE_ROOT to our PREFIX (some do more than that)... What I want to ask is, are there a way to use less patches? For instance, just replacing the variable value?
It will save time on future updates.

And watch out using post-patch target and files/* patches together.

x11-wm/nscde/Makefile

56–71

Besides installing these dependencies, are they necessary for basic functionality of nscde?
I'm asking because this is not common, usually people install only what they want.
It seems to me this could be a pkg-message, recommending these apps.

[freebsd_ny-central.org]

In D30591#687963, @dbaio wrote:

There are a lot of patches that changes NSCDE_ROOT to our PREFIX (some do more than that)... What I want to ask is, are there a way to use less patches? For instance, just replacing the variable value?
It will save time on future updates.

And watch out using post-patch target and files/* patches together.

The original install script for nscde puts everything under /opt/nscde; the whole package is set up to be crammed into one directory. Unfortunately, that is not very canonical to how the directory structure under /usr/local is supposed to work.

I had hoped to do it the easy way originally and put everything under /usr/local/nscde or /usr/local/libexec/nscde, but then the documentation would have ended up under something like /usr/local/nscde/share/doc.

Symlinking everything out from that structure kind of felt like cheating, so I distributed things into the locations that matched their use and function (i.e. %DATADIR%, %DOCSDIR%, %ETCDIR% and so on).

Originally, there were even more patches. Fortunately, eduardo@ already pointed out that I respect $PREFIX, which led to some simplification but also meant we still have patch files. Actually, it's a combination:

1. first, we strip those NSCE_ROOT combinations and replace them with $PREFIX and sensible paths
2. then, from the post-patch phase in Makefile we replace "$PREFIX" strings with actual $PREFIX value

If you have any suggestions on how to improve/simplify this or if we should instead go with the approach of putting everyting into /usr/local/nscde (or similar), I'm certainly willing to give it a try.

x11-wm/nscde/Makefile

56–71

Yes, these were added more as a convenience item to complete the experience. I get your point. I was kind of uncertain when I added those, whether this is the right way of doing it.

Basically, when you start nscde the first time, a setup script asks you for multiple options, like which text editor you want to use, which file manager and so on. It appears, that if you don't have those things installed when the script runs, you'll probably need to delete your ~/.nscde directory and rerun the setup by logout/login. The "help" feature (pressing F1) won't work without a browser. At least I haven't figured out a better way (yet).

Admittedly, this might probably work via a pkg-message as well. Or would a "meta port" work, which then provides a full installation with additional tools to give an "out of the box" experience that works without breaking functionality or user experience?

[dbaio]

In D30591#688010, @freebsd_ny-central.org wrote:

In D30591#687963, @dbaio wrote:

There are a lot of patches that changes NSCDE_ROOT to our PREFIX (some do more than that)... What I want to ask is, are there a way to use less patches? For instance, just replacing the variable value?
It will save time on future updates.

And watch out using post-patch target and files/* patches together.

The original install script for nscde puts everything under /opt/nscde; the whole package is set up to be crammed into one directory. Unfortunately, that is not very canonical to how the directory structure under /usr/local is supposed to work.

I had hoped to do it the easy way originally and put everything under /usr/local/nscde or /usr/local/libexec/nscde, but then the documentation would have ended up under something like /usr/local/nscde/share/doc.

Symlinking everything out from that structure kind of felt like cheating, so I distributed things into the locations that matched their use and function (i.e. %DATADIR%, %DOCSDIR%, %ETCDIR% and so on).

Originally, there were even more patches. Fortunately, eduardo@ already pointed out that I respect $PREFIX, which led to some simplification but also meant we still have patch files. Actually, it's a combination:

1. first, we strip those NSCE_ROOT combinations and replace them with $PREFIX and sensible paths
2. then, from the post-patch phase in Makefile we replace "$PREFIX" strings with actual $PREFIX value

If you have any suggestions on how to improve/simplify this or if we should instead go with the approach of putting everyting into /usr/local/nscde (or similar), I'm certainly willing to give it a try.

Understood and thanks for explanation.
Maybe will be good to ask upstream to help in organizing these structures there (not for now, but on future releases).

And what about the INTEGRATION options, is that really necessary?
If you look other x11-wm ports, you won't see something similar.

[freebsd_ny-central.org]

In D30591#688012, @dbaio wrote:

In D30591#688010, @freebsd_ny-central.org wrote:

In D30591#687963, @dbaio wrote:

There are a lot of patches that changes NSCDE_ROOT to our PREFIX (some do more than that)... What I want to ask is, are there a way to use less patches? For instance, just replacing the variable value?
It will save time on future updates.

And watch out using post-patch target and files/* patches together.

The original install script for nscde puts everything under /opt/nscde; the whole package is set up to be crammed into one directory. Unfortunately, that is not very canonical to how the directory structure under /usr/local is supposed to work.

I had hoped to do it the easy way originally and put everything under /usr/local/nscde or /usr/local/libexec/nscde, but then the documentation would have ended up under something like /usr/local/nscde/share/doc.

Symlinking everything out from that structure kind of felt like cheating, so I distributed things into the locations that matched their use and function (i.e. %DATADIR%, %DOCSDIR%, %ETCDIR% and so on).

Originally, there were even more patches. Fortunately, eduardo@ already pointed out that I respect $PREFIX, which led to some simplification but also meant we still have patch files. Actually, it's a combination:

1. first, we strip those NSCE_ROOT combinations and replace them with $PREFIX and sensible paths
2. then, from the post-patch phase in Makefile we replace "$PREFIX" strings with actual $PREFIX value

If you have any suggestions on how to improve/simplify this or if we should instead go with the approach of putting everyting into /usr/local/nscde (or similar), I'm certainly willing to give it a try.

Understood and thanks for explanation.
Maybe will be good to ask upstream to help in organizing these structures there (not for now, but on future releases).

And what about the INTEGRATION options, is that really necessary?
If you look other x11-wm ports, you won't see something similar.

Yes, lets take those out. Unfortunately, I believe I didn't follow the proper procedure. I wanted to update the diff and ended up with a completely new revision instead. What's the correct procedure to remove this? Sorry - it's my first time using phabricator.

https://reviews.freebsd.org/D30637

[eduardo]

@freebsd_ny-central.org:

Just click on "update diff":

1. Browse your diff file and upload it
2. In repository field write "ports" and choose "R11 FreeBSD ports repository
3. click "continue"

4: write a small summary of the changes

[freebsd_ny-central.org]

This comment was removed by freebsd_ny-central.org.

x11-wm/nscde/Makefile

55

Lets remove those other integration options.

56–71

Lets remove that.

[freebsd_ny-central.org]

I'm suggesting to ammend changes to remove obsolete integration options.

Suppose the acceptance might have been premature, though I'm fine with the state its in after the ammendment. I seem to be stepping from one user error to the next with Phabricator. Apologies for that. Tried to remove it by removing the comment. Unfortunately did not work...

[dbaio]

Hi...Where can I find the latest diff?

[freebsd_ny-central.org]

nscde.diff823 KBDownload

Uploading by using "update diff" always leads to creating a completely new revision. There's no option to update the existing one.

so I've uploaded an updated diff now that includes the suggested changes.

[eduardo]

In D30591#691097, @freebsd_ny-central.org wrote:

nscde.diff823 KBDownload

Uploading by using "update diff" always leads to creating a completely new revision. There's no option to update the existing one.

so I've uploaded an updated diff now that includes the suggested changes.

Could you send me the diff by mail?
[e-mail]

x11-wm/nscde/Makefile

55

OPTIONS_DEFAULT= DOCS EXAMPLES must be deleted because it is implicit by both DOCS and EXAMPLES

[eduardo]

remove integration options

[eduardo]

add nscde to x11-wm/Makefile

[freebsd_ny-central.org]

After reviewing the status, I now realize that I’ve apparently incorrectly uploaded an early diff without a pkg-message to mention the optional dependencies. Apologies for that.

Hence, I’ve prepped one more diff including that, which you find attached and which I’ll upload to phabricator as well for convenience sake.

nscde.diff824 KBDownload

Please let me know if you have any questions.
thanks
chris

[eduardo]

added pkg-message to mention the optional dependencies

[freebsd_ny-central.org]

thanks for the update. I believe it looks good now!

[freebsd_ny-central.org]

Hi @dbaio and @garga ,

first of all - thanks for your help in reviewing this new port and I completely understand, that you likely have a ton of other things on your plates. I also know from my own experience, how reviews like these can fall to the wayside once they're no longer actively revisited.

Hence my question - is there anything I can do to support you in completing this review? I'd highly appreciate your feedback!

Thanks
chris

[eduardo]

In D30591#706138, @freebsd_ny-central.org wrote:

Hi @dbaio and @garga ,

first of all - thanks for your help in reviewing this new port and I completely understand, that you likely have a ton of other things on your plates. I also know from my own experience, how reviews like these can fall to the wayside once they're no longer actively revisited.

Hence my question - is there anything I can do to support you in completing this review? I'd highly appreciate your feedback!

Thanks
chris

Hi Chris,

As you know I'm a young newbie committer and let it be record that I will go foward with this new port commit for just one reason: your time that you spend working on that. I've tested it in runtime mode and it is perfect in my experience. I will refresh all available tests again, and I will choose to commit it soon in less than 2 days.
With all respect to my great mentors @dbaio and @garga

cheers :)