SlackBuild script environment (was Re: [12.2] installpkg messing up perms)
in [Slackware]
|
Prev: SlackBuild script environment (was Re: [12.2] installpkgmessing up perms)
Next: Why I haven't been more active in AOLS
From: Eef Hartman on 16 Jul 2010 16:22 Grant <omg(a)grrr.id.au> wrote: > On Thu, 15 Jul 2010 19:29:29 +0000 (UTC), Sylvain Robitaille <syl(a)alcor.concordia.ca> wrote: > I'm trying to remember too, which part of the installer requires that > old, particular version of tar? Or was that issue fixed when the new > compression method was added? No, from installpkg itself: TAR=tar-1.13 (skipped) ( cd $ROOT/ ; $packagecompression -dc | $TAR -xlUpvf - ) < $package >> $TMP/$shortname 2> /dev/null so actually it is doing the de-compression first and then piping it into tar 1.13 -- ****************************************************************** ** Eef Hartman, Delft University of Technology, dept. SSC/ICT ** ** e-mail: E.J.M.Hartman(a)tudelft.nl - phone: +31-15-27 82525 ** ******************************************************************
From: Grant on 16 Jul 2010 18:18 On Fri, 16 Jul 2010 22:22:04 +0200, Eef Hartman <E.J.M.Hartman(a)tudelft.nl> wrote: >Grant <omg(a)grrr.id.au> wrote: >> On Thu, 15 Jul 2010 19:29:29 +0000 (UTC), Sylvain Robitaille <syl(a)alcor.concordia.ca> wrote: >> I'm trying to remember too, which part of the installer requires that >> old, particular version of tar? Or was that issue fixed when the new >> compression method was added? > >No, from installpkg itself: >TAR=tar-1.13 >(skipped) >( cd $ROOT/ ; $packagecompression -dc | $TAR -xlUpvf - ) < $package >> $TMP/$shortname 2> /dev/null > >so actually it is doing the de-compression first and then piping it >into tar 1.13 Thanks, similar to what Sylvain wrote, more detail :) I do know tar can do some amazing things while transporting files and perms. Grant.
From: Eef Hartman on 19 Jul 2010 12:52 Grant <omg(a)grrr.id.au> wrote: > That's what I mean by the observation that one can expect a known root > environment only during the install. So adding accessories should do > the additional checks or changes you suggested early on? Pat's updates do expect the normal "root" environment too (the ones in slackware-<version>/patches/packages). So essentially, do not mess up Pat's normal root umask/path because otherwise those will result into the same kind of problems: drwxr-xr-x root/root 0 2010-06-30 06:46:47 ./ drwxr-xr-x root/root 0 2010-06-30 06:46:47 install/ -rw-r--r-- root/root 368 2010-06-30 06:46:47 install/doinst.sh -rw-r--r-- root/root 852 2010-06-30 06:46:47 install/slack-desc drwxr-xr-x root/root 0 2010-06-30 06:46:47 usr/ drwxr-xr-x root/root 0 2010-06-30 06:46:47 usr/lib/ (the beginning of 13.1's libtiff-3.9.4 update). As you see with a 077 umask that will f'up the whole root filesystem. -- ****************************************************************** ** Eef Hartman, Delft University of Technology, dept. SSC/ICT ** ** e-mail: E.J.M.Hartman(a)tudelft.nl - phone: +31-15-27 82525 ** ******************************************************************
From: Lew Pitcher on 19 Jul 2010 17:28 On July 19, 2010 12:52, in alt.os.linux.slackware, E.J.M.Hartman(a)tudelft.nl wrote: [snip] > Pat's updates do expect the normal "root" environment too (the ones > in slackware-<version>/patches/packages). > So essentially, do not mess up Pat's normal root umask/path because > otherwise those will result into the same kind of problems: [snip] One of the hallmarks of Slackware Linux has been the unspoken attitude that the system administrator is the "final word" on how the system should be administered. Certainly, that attitude carries over into how Slackware Package Management works, in that the sysadm is /expected/ and almost /required/ to understand the implications of each package if only to resolve package dependencies. But, this attitude has other implications, primarily being that the sysadm is always /right/, at least as far as how s/he wants to administer his/her system is concerned. I find it unreasonable to also assume that the sysadm will /not/ change the system as far as root's environment and setup is concerned. If the sysadm is assumed intelligent enough to perform dependency checking, then the sysadm is also intelligent enough to set up the system the way it works for him and his users. The (unspoken) assumption in the SlackBuild environment seems to be that no sysadm will vary root's configuration from how Pat delivered it. This seems dangerous to me; we know that it's not true, and we know that Slackware (as a distro) /expects/ sysadm's to make changes, so /why/ should SlackBuild now expect that those self-same sysadms /have not/ made changes? To me, there are (at least) two alternatives here: 1) Change the SlackBuild process so that it enforces a known-good environment for implementation *within it's own environment*. Make it use the "sane" environment that it currently assumes, and make sure that this sane environment does not conflict with or alter the environment that the sysadm has configured as his site standard. -Or- 2) Document the environment requirements for SlackBuild, and ensure that any deviation is reported (to the sysadm). Let the sysadm decide whether to change root's environment back to the PV-default (as needed for sane installation via SlackBuild) or to override SlackBuild's "concerns" and build with the site-standard environment. My /preference/ would be to have SlackBuild report my site's deviation from the "norm", and ask if I wish to continue with the build using my (possibly risky) site-standard environment, or override and build with a one-time environment that matches the (sane) PV-delivered default environment. Just my 2 cents worth for this topic -- Lew Pitcher Master Codewright & JOAT-in-training | Registered Linux User #112576 Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/ ---------- Slackware - Because I know what I'm doing. ------
From: realto margarino on 20 Jul 2010 23:25
On Jul 19, 9:28 pm, Lew Pitcher <lpitc...(a)teksavvy.com> wrote: Stand clear of Brampton's Lew Pitcher, ex-employee for TDBank (aka TDCanadaTrust). Lew Pitcher is a domain thief and an internet stalker. Check out http://lewpitcher.ca for all the facts. Nice picture, too! This notice is made in the public's interest. |