From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 17 Nov 2002 04:40:54 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 372 ************************************************** Saturday 16 November 2002 Number 372 ************************************************** Subjects for today 1 Re: installpkg : Andreas Buening 2 Re: config.site : Michael Zolk **= Email 1 ==========================** Date: Sun, 17 Nov 2002 01:25:56 +0100 From: Andreas Buening Subject: Re: installpkg Michael Zolk wrote: > > On Thu, Nov 07, 2002 at 12:26:30AM +0100, Andreas Buening wrote: > > > > I guess this would be me :) Have you seen the latest version I uploaded > > > recently? I tried to change the directory structure to comply with the FHS. > > > > Not yet. > > I would appreciate it if some of you could check if the directory structure > is OK now. Changing it at a later date would probably mean a bit of trouble > for everybody :> That's for sure. ;-) I apologize for the late response. I guess, you're talking about that installpkd.cmd from 30 Oct 2002? > > > I'd like to keep installpkg relatively small. One idea would be > > > to include scripts or small exes in the ux2_base pkg that perform these > > > common tasks like replacing/adding drive letters, creating desktop objects, > > > modifying configuration files. > > > > No. Every maintainer should be able to add an installation script > > to "his" package without bothering the ux2_base maintainer. > > Of course every maintainer can write his own script and put it in /install. > What I meant was that these scripts should probably somehow rely on e.g. > other Rexx scripts that do things like those mentioned above in a > standardized way, e.g. it would be possible to write something like > "CALL abspath.cmd '/usr/bin/shellscript.sh'" in a rexx install script to > expand the pathnames in shellscript.sh. The idea of /bin, /lib and /sbin is that _all_ stuff that is necessary for the installation has to be there. If you really need another rexx script for the installation we must add it to /bin or /sbin. > > I think installpkd should also not execute scripts specified > > by the SCRIPT keyword due to the following reason: > > If a user installs e.g. a library as the first package then it's not > > possible to execute any sh script because there is no sh.exe or any > > other GNU tool. > > This is indeed a problem. I don't know how all the Linux distros handle > this. Hmm, good question. Does anybody know? > This is the reason why all the scripts in ux2_base are Rexx scripts - > they only need the stuff that's already present on an OS/2 system. I'm not > sure if we should simply define that install scripts _have to be_ Rexx > scripts. No, not in general. My idea for the installation process is as follows: 0) - Change OS/2 variables (PATH, LIBPATH, ...) - Add Unix/Posix variables (HOME, LOGNAME, ...) - Add UnixOS/2 variables (UNIXROOT, TMPDIR) - Reboot if necessary 1) installpkg puts the UnixOS/2 core packages (/bin and /lib) in place. All installation scripts and file lists are stored somewhere in /var without executing them. After this has been done we have all necessary installation tools available (That's the definition of /bin and /lib: necessary for installation and maintainance). 2) Run "ux2-update" the first time which a) executes those scripts and b) updates some databases/whatever. 3) Now the base system is working and it's possible to install any number of other packages by installpkg and run "ux2-update" again. Because of that all install scripts can rely on every tool that is in /bin. I.e. sh or even sed scripts are allowed but perl scripts are not (because perl is in /usr/bin). [snip] > > > I did it this way because it should be easier to handle locked files or > > > other errors this way. > > > > That's true. However, it'll definitely too slow for a zip file of > > several hundred files. And if you have hundreds of them ... :-) > > I don't know an immediate solution. Maybe installpkg just unpacks > > the archive into a temporary directory (/var/tmp/install.tmp?). > > If that's successfull it _moves_ all files into their correct > > position. > > I guess this would be a solution. Another question is what happens with locked files? Some thoughts about your PKGINFO keywords. I encountered a lot of questions when I read your manpages. These reflect just my ideas and aren't well ordered: PKGNAME pkgname Where exactly is the PKGINFO file copied? /var/lib/unixos2/packages/.??? VERSION version-string Make it mandatory. It would cause the maintainers to use a version number. Installing an old version over a new one could cause an error. What about a "TYPE {CORE|USR|LOCAL|OPT}" keyword that specifies which kind of package you have? USR, LOCAL or OPT packages could be less restrictive. E.g. non CORE packages may use sh scripts for PREINST script. Or removepkg could give an error if anybody tries to remove a CORE package. DESC description Is this info printed? A message like "Do not install this package if ..." might be helpful. If this is the case then a comment that is not printed (REM?) might helpful, too. REQUIRES pkgname libunixos2 is just a special lib. I suggest to use no REQUIRES keyword for any package that is in /bin or /lib. It's hard sometimes to find out which one of the GNU tools is used and which one not. SCRIPT {PREINST|POSTINST|POSTDEL} scriptname At least the POSTINST scripts can be sh scripts. Where are these scripts stored? How do you avoid name collisions? The SCRIPT keyword could guarantee that the current drive is UNIXROOT when the script is executed. Is it possible to execute a single command like "install-info --info-dir=/usr/share/info /usr/share/info/foo.info"? About every package requires a line like this for its .info file. FILE pathname [owner group mode] Adding hundreds of file to PKGINFO could be very time consuming. What about "FILE ALL" which installs all files automatically? What is the sense of "owner"? Currently, we have no file "owner". If we had this feature it would be possible to install files for another user (e.g. "root") but after that we might have no access to these files anymore, i.e. we wouldn't even be able to uninstall them. How do I specify "mode"? E.g. how to produce a readonly file? Another question: What happens if installpkg encounters a readonly file that has to be replaced by a new one? Just overwrite it or ask the user what to do as it is the case when applying an OS/2 fixpack? What about a "NOINSTALL file" keyword. A package might contain some files that shouldn't be installed (a COPYING file or a special README). PKGINFO has the "NOINSTALL" attribute by default. What about a "OVERWRITE {YES|NO}" keyword. If the file structure of a package changes between different releases then the new package gets "OVERWRITE NO" which means the old package must be uninstalled first. Even the "-f" switch won't install the new version over the old one (to avoid that files from the old version are left). CONFFILE pathname [owner group mode] What exactly is the difference between CONFFILE and FILE? Will the user be prompted for every CONFFILE as if it were readonly? SYMLINK fromfile tofile It just copies files, I guess. DEVICE pathname {c|b} major minor What does this keyword do? I guess, nothing. Are there any packages that really need to create a device? What happens to the PKGINFO file if "FILE ALL" is used? Will all "automatically added" files be added to the PKGINFO in /var/lib/...? What about HISTORY file? Every installation script could add a single line to the history file like "10 Oct 2003 installpkg 1.2.3: foo 1.2.3 installed" How can installpkg tell "ux2-update" what it has to do? Maybe installpkg stores all necessary commands in a file /var/lib/unixos2/install/.xyz. and "ux2-update" executes all commands listed within that file before it deletes that file. That file could look like install-info ... /usr/share/info/foo.info /var/lib/unixos2/scripts/foo-inst.sh A big issue is also how to handle the doc files. Do we need a "INSTALL {INFO|MAN|HTML|whatever} file" keyword? Or can "ux2-update" perform this operation automagically for all new files? Okay, I guess, that's enough for now. Some of what I said may be important, some may be less important and can be implemented later and some might be nonsense. ;-) However, I hope, I haven't confused you. At least the treatment of those .info files depends on whether you think it'll be easier to implement this way or that way. Btw, do you know of help2man? It's a small perl script that can create a manpage from the "--version" and "--help" output of your program. The advantage is that the manpage is automatically up to date. Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 2 ==========================** Date: Sun, 17 Nov 2002 22:30:17 +0100 From: Michael Zolk Subject: Re: config.site On Thu, Nov 14, 2002 at 10:53:04PM +0100, Andreas Buening wrote: > No, config.site is a file that is read by every configure script if > CONFIG_SITE is set. You can put system dependend stuff there, e.g. > transform '\' into '/' in your PATH, setting ac_executable_extensions. > It's not a must have, but it's neither a part of the "real" system > (/usr) nor it's some kind of "variable data" (/var). I would consider > it as a "configuration file that can be edited by the user" (/etc) > and is optional. It doesn't really belong to anything so I'd prefer > to put it into the core package of the UnixOS/2 core packages. ;-) OK, if you can mail me your config.site, I will include it in ux2_base. However, in the long run it might be good to create a "development core package" that contains stuff like this. Michael -- NP: Motörhead - Beer Drinkers and Hell Raisers