Author Topic: Pathmappers, HOME, ETC and others...my oh my!!!  (Read 3804 times)

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Pathmappers, HOME, ETC and others...my oh my!!!
« on: January 20, 2021, 05:03:07 pm »
Dave's response to a question Rick posted in this thread (https://www.os2world.com/forum/index.php/topic,2714.msg0.html#new) has reminded me of something.

A while back - as I was transitioning to RPM/YUM - I embarked on a house-cleaning project, meaning: try to reconcile the various application config with the new RPM/YUM/*nix porting approaches.

That has meant figuring out what to put where, and what really are the preferred/correct uses and the matching locations for things such as:

1) \MPTN\ETC
2) \ETC
3) \HOME

The 'kLIBC - Pathwrewriters' utility allows you to configure some of this stuff. Truth be told though, I am no longer certain whether what I have in there right now is part of the "default" install for stuff like RPM/YUM/ANPM, or was it perhaps tweaked by me at some point in time (maybe part of that transitioning effort I mentioned above?).

So here are the contents of my 'kLIBC - Pathwrewriters' utility:
1) /var/log => %LOGFILES%
2) /tmp => %TMP%
3) /etc => %YUM_RPM_ETC%

where these environment variables are in turn mapped to:

1) %LOGFILES% => \tmp\log
2) %TMP% => \tmp
3) %YUM_RPM_ETC% => \etc

The other, somewhat standard (for the most part I think) environment variables are:
1) %HOME% => \home
2) %ETC% => \mptn\etc
3) %TMPDIR% => ramdisk:\GCC (really for the single DEV purposes)
4) %TMP% => ramdisk:\tmp
5) %TEMP% => ramdisk:\tmp
6) %LOGFILES% => \tmp\log

Further on, even the RPM applications (the ported stuff) usually stores stuff into either %ETC% (which is \mptn\etc here), or %YUM_RPM_ETC% (which is \etc here) or %HOME% (which is \home here).

Soooo....yeah, to this guy here it still feels like stuff is "all over the place"  ???

Therefore, I am curious what strategies (if any) have others developed to reconcile this stuff and create a better, perhaps more consistent configuration?

Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 827
  • Karma: +14/-0
    • View Profile
Re: Pathmappers, HOME, ETC and others...my oh my!!!
« Reply #1 on: January 20, 2021, 07:11:20 pm »
Not really an improvement: I let the installers do all things for me.

After the ArcaOS installation, I point UNIXROOT to another drive with existing trees for \usr, \var and \etc.
I change also the three TMP values, VAR, LOGFILES, HOME, MOZILLA_HOME and MOZ_PLUGIN_PATH to dirs an other drives.
The steps above are not done for service or test installations, just for the main one.

I don't change the initial kLIBC path rewriter values.
I don't see a reason to change the initial ETC env var.
« Last Edit: January 20, 2021, 07:15:21 pm by Andreas Schnellbacher »

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Pathmappers, HOME, ETC and others...my oh my!!!
« Reply #2 on: January 20, 2021, 08:13:52 pm »
Quote
Soooo....yeah, to this guy here it still feels like stuff is "all over the place"  ???

It probably is, since you have been doing that, for years.

Quote
Therefore, I am curious what strategies (if any) have others developed to reconcile this stuff and create a better, perhaps more consistent configuration?

The EASY way, is to do a new ArcaOS install, and never do anything on your own. Let ANPM do it properly, for you. If you do find something that needs special stuff, put it all in it's own directory, and add paths to the END of the path statements, so that the proper stuff is found first (actually, that isn't true, because ANPM insists on the .; entry first, which tries to load things from the working directory. IMO, that is not a good idea, but others seem to think it is a good idea. If that doesn't work, remove the added paths, and use the Environment tab in the program icons (part of DragText - READ the instructions). You may also need to use LIBPATHSTRICT.

You can spend a lot of time trying to fix past sins, and still not get all of it. So far, I have not found any reason to add my own stuff, but I do use the Environment tab for a few things (not because of YUM). It can help to shorten the paths, by using a custom PATH, and BEGINLIBPATH/ENDLIBPATH adds to what is set in LIBPATH in CONFIG.SYS.

Quote
I let the installers do all things for me.

That is the only safe way to do it. Theoretically, whoever built the installer, knows what is required, so it does it right (sometimes, that isn't exactly true, and sometimes, old installers don't know about newer requirements). One of the things, that old installers, will do, is add the PATH and LIBPATH statements to the beginning of the lines. Anybody who is building an installer should put the new stuff at the end, so you don't break something else. There is something wrong with your package, if it really does need to be first.

Quote
After the ArcaOS installation, I point UNIXROOT to another drive with existing trees for \usr, \var and \etc.

I was doing that, so I could share the RPM/YUM install with another boot drive. I quit doing it because it was becoming an administration problem. There are just too many things that RPM/YUM does to individual boot drives, and sharing only knows about the boot drive that is active when you do the updates. It wouldn't be a problem, if you don't share with another boot drive.

Additionally, you really should point the installer to the existing drive, so it can do the necessary updates during install (especially if it is an UPDATE install).

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: Pathmappers, HOME, ETC and others...my oh my!!!
« Reply #3 on: January 21, 2021, 02:35:20 pm »
Andreas and Doug,

Part of my challenge here is that I have an old Warp4 => CP2 => SMP => "whatever it is now" wonder setup... ;D, and while it works nearly 99% of the time (especially now that I finally got my CPU core issue resolved), it still does have some left-over warts and blisters here and there!

Point being, my OS/2 installation today has at least a couple of decades of software on it, there is no way I'm going to move to a fresh OS install such as AOS, not even remotely possible. Would love to do it, but the legacy of stuff I have on here just doesn't allow me to pursue that option. If it came down to it I unfortunately would simply move on to another platform. Don't get me wrong, OS/2 is always going to "feel right", but if a re-install is needed I might as well invest that effort and time into a platform that truly allows me to take my computing experience to the next level, and that's something we will never see happen on our platform.

Soo...in the meantime, I continue to enjoy my OS/2 experience such as it is - with all the different 'part of the fun' pieces, and look for ways to better maintain and re-adjust as new solutions arrive.

Appreciate both suggestions though, it's just that they are not viable here.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Pathmappers, HOME, ETC and others...my oh my!!!
« Reply #4 on: January 21, 2021, 07:26:38 pm »
Quote
Part of my challenge here is that I have an old Warp4 => CP2 => SMP => "whatever it is now" wonder setup... ;D, and while it works nearly 99% of the time (especially now that I finally got my CPU core issue resolved), it still does have some left-over warts and blisters here and there!

If you have it working 99%, you are doing well.

Quote
Point being, my OS/2 installation today has at least a couple of decades of software on it, there is no way I'm going to move to a fresh OS install such as AOS, not even remotely possible.

It is easier than you think, and getting rid of decades of garbage is well worth the effort, but that is your choice. The main thing, is to separate the OS from the programs/data, so you can update the OS part, without making changes to the programs/data. If Arca Noae manages to get UPDATE from Warp 4.5 working, you may be able to do it that way, but I suspect that older systems are going to have way too much garbage in them, to make it possible.

What I do, is have two boot volumes. One is the current one, and the other is the previous one, where I install a new one, then get it working, while still using the current one. After the new one is working, I switch, and the new one becomes current, while the old one waits for the next update. It is also useful as a "maintenance" volume.