Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#341 closed defect (no change needed)

_datadir macro unsuitable for use with os2_langdir, os2_bookdir, os2_helpdir

Reported by: Lewis Rosenthal Owned by:
Priority: major Milestone:
Component: rpm Version:
Severity: highest Keywords:
Cc:

Description

os2_langdir, os2_bookdir, and os2_helpdir (and possibly more) macros rely on _datadir to provide the first portion of their paths. Unfortunately, _datadir points to:

%{_prefix}/share (i.e., /@unixroot/usr/share)

which is not very useful when attempting to install something in, say, %BOOKSHELF% (X:\OS2\BOOK) using the os2_bookdir macro.

I would suggest that once ticket #340 has been fully vetted, these macros be reviewed for accuracy, so that os2_helpdir, etc. start with os2_boot_drive, instead.

Change History (5)

comment:1 Changed 4 years ago by Silvan Scherrer

this is working as designed. We add the new directories to BOOKSHELF, HELP and DPATH. And mixing such infos with original OS2 ones is a bad idea. So using this macros to add something to x:\os2\books is not supported and will never be.

be aware that also here the macro expansion might be wrong right now. So it might be wrong path got added to BOOKSHELF and friends.

comment:2 Changed 4 years ago by Lewis Rosenthal

Ah, yes, I see. I should have read os2-base.spec more closely. The macro names were slightly misleading to my way of thinking, but I understand better, now. Thanks.

Still, as you say, the current expansion issue may lead to unpredictable results.

comment:3 Changed 4 years ago by Silvan Scherrer

Resolution: no change needed
Status: newclosed

this will be fixed in #340, so closing this.

comment:4 Changed 4 years ago by dmik

Yes, Silvan is right — it works as designed. %{os2_langdir} and friends are supposed to be used in .spec only (i.e. when creating and installing RPM packages). Given that they use /@unixroot it will be always correct regardless of the real UNIXROOT value on a particular machine.

You may in fact think on using these macros in some other context where it may expose "unpredictable results" (like putting an entry to a confiuration file of a program that doesn't use kLIBC runtime and can't access /@unixroot) but there are solutions for that. I.e. to get a DOS path with %UNIXROOT% instead of /@unixroot (suitable for running commands via cmd.exe) you may use the %{os2_dos_path} RPM macro (see os2-base.spec for an example). This will always work correctly.

If you need it in a non-CMD context where expansion of %UNIXROOT% is not available, you will have to use %{os2_expand_unixroot} to get the real path with no /@unixroot and env.vars at all. However, this requires several steps to add secondary expansion to .spec in order to take the target machine-s UNIXROOT setting at install time (rather the package creator's UNIXROOT setting). I've added http://trac.netlabs.org/rpm/wiki/RpmHowToPackagers#Usingmacrosatinstalltime to clarify all that.

Note that the CONFIG.SYS section in the above manual will also change once we sort out #340.

comment:5 Changed 4 years ago by Lewis Rosenthal

Thanks for the additional info, Dmitriy. Much appreciated. Time for me to re-read the wiki, in any case.

Note: See TracTickets for help on using tickets.