Cosmetic Surgery: Preparation for packaging

[funilrys]

Hi @veracioux,

As my main machine is under Arch Linux I started the packaging of this project. While packaging I found some cosmetic issues that don't fit.

Can you please review and merge my changes ?

Changes

• username switched from harisgusic to veracioux
• version updated in makefile.
• annoying double slashes removed.

Questions

Do you plan to rename your __XYZ variables ? I had to patch them to match this style:

• /etc/tuterm/config.sh (system-wide configuration)
• /etc/tuterm/scripts (system-wide scripts)

Stay safe and healthy!

[veracioux]

Hey @funilrys. Thank you very much for the changes, and for your interest in the project. There is already an AUR package if that's what you are going for. We should update the existing package with these changes. If you are coming from #1, I realize that I should have made it more clear that there is an AUR package, and I updated the issue so other people don't get confused.

• username switched from harisgusic to veracioux

Thanks, when I changed my username, there were a bunch of projects I had to update so some slipped through.

• version updated in makefile.

I have to remember to update that!

• annoying double slashes removed.

I am also annoyed by the double slashes, but I included them to prevent unintended behavior when someone calls make by hand and forgets them. But I trust that you are more experienced than me, so I'm fine with this change.

Do you plan to rename your __XYZ variables ? I had to patch them to match this style:

• /etc/tuterm/config.sh (system-wide configuration)

• /etc/tuterm/scripts (system-wide scripts)

Where did you patch them? And why is that a requirement? I've seen many (in my experience almost all non-administrative) packages that use /usr/share/... for system wide stuff. Please elaborate more.

Stay safe and healthy!

You too, stay safe and healthy!

[veracioux]

@funilrys I have read your comment on the AUR. Would you care to discuss it a little with me on matrix?

[funilrys]

So, finally got some time to look into this.

If you are coming from #1, I realize that I should have made it more clear that there is an AUR package, and I updated the issue so other people don't get confused.

Yup, I got confused, but I explained in the discussion channel, it's also an internal choice of me.

I am also annoyed by the double slashes, but I included them to prevent unintended behavior when someone calls make by hand and forget them. But I trust that you are more experienced than me, so I'm fine with this change.

As far as I am aware, if someone is running is manually without building, they will get /usr/local. The only way to change that is through build or manual editing. I assume that most people who use OSS software or scripts are able to get around this problem. Therefore, there shouldn't be any issue for normal people.

Where did you patch them? And why is that a requirement? I've seen many (in my experience almost all non-administrative) packages that use /usr/share/... for system wide stuff. Please elaborate more.

I'm just trying to following the guideline-s. To quote the Arch package guideline:

• Configuration files should be placed in the /etc directory. If there is more than one configuration file, it is customary to use a subdirectory in order to keep the /etc area as clean as possible. Use /etc/{pkgname}/ where {pkgname} is the name of the package (or a suitable alternative, eg, apache uses /etc/httpd/).
• Package files should follow these general directory guidelines:
  • /etc : System-essential configuration files
  • /etc/{pkg}: Configuration files for {pkg}
  • /usr/bin: Binaries
  • /usr/lib: Libraries
  • /usr/include: Header files
  • /usr/lib/{pkg}: Modules, plugins, etc.
  • /usr/share/doc/{pkg}: Application documentation
  • /usr/share/info: GNU Info system files
  • /usr/share/man: Manpages
  • /usr/share/{pkg}: Application data
  • /var/lib/{pkg}: Persistent application storage
  • /opt/{pkg}: Large self-contained packages

Therefore, I patched my own version of the package as follow:

sed -i -E "s|(__SYSTEM_CONFIG=)(.*)|\1\"/etc/${pkgname}/config.sh\"|g" "${pkgname}"
sed -i -E "s|(__SCRIPT_PATH=)(.*)|\1\"/etc/${pkgname}/scripts\"|g" "${pkgname}"

By installing the configuration file into /etc/{pkg}, I have a global configuration file that is at a know place. I mean, all sysadmins I know will first look into /etc/{pkg} ... Most sysadmins I know (and It's probably true globally) consider /usr/share/* as a place for the package itself. It's like a black door that nobody want to get through (or customize). But that's still a personal opinion based on my experience.

Feel free to edit this patch before merging.

Stay safe and healthy.

[veracioux]

@funilrys Thank you for the detailed elaboration. I will change the config directory in the project to /etc/tuterm. But I think the scripts should stay in /usr/share/tuterm/scripts instead of moving them to /etc/tuterm/scripts. This is more in line with the guidelines.

[funilrys]

@veracioux, I have an argument for that too 😄

I played with tuterm the past few days and it's really not bad. My family is trying to understand, git, bash and some other things that make my Linux experience so entertaining for them to watch. So I found tuterm extremely useful for that case.

I deploy my own scripts/tutorials into /etc/tuterm/scripts with ansible and then they only have to run or play with them. As I previously said, /usr/share is a black box that no sysadmin wants or should have to play with. Therefore, the /etc/tuterm structure is just perfect.

I have the experience that makes me aware of that. I'm a bit hardcore and I don't have any problem breaking and repairing a package or a distribution - that's what I do at home and with even more fun at work. But while explaining or maintaining things to people who tends to have less fun regarding "hardcore measures", it's important to provide a safe white-box that anybody cat repaint 😄.

You won't prevent me to overwrite the path in my local network 😝

[veracioux]

@funilrys I'll make it so that /etc is used (you convinced me).

I'm glad you like tuterm. If you think your personal tuterm scripts could be useful to other people, consider adding them to https://github.com/veracioux/tuterm-collection