installpkg messing up perms
in [Slackware]
|
From: Eef Hartman on 19 Jul 2010 13:53 Sylvain Robitaille <syl(a)alcor.concordia.ca> wrote: > This all suggests, however, that perhaps the scripts at Slackbuilds.org > don't explicitly set a umask, and I would argue that this is an > oversight that should be corrected. Actually, neither do all of the build scripts in the source tree of Slackware itself. They all depend on the "as distributed" root environment. Look i.e. at the build script for the libtiff update I quoted earlier: slackware-13.1/patches/source/libtiff/libtiff.SlackBuild PS: I must correct myself on that previous message: tar _as root_ will create the dir owners and atributes correctly WHEN they are correct in the .txz (cq .tgz for releases 12.x and earlier) package, the root's umask will only be applied to any files, created in the doinst.sh script. -- ****************************************************************** ** 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 19 Jul 2010 17:00 On Mon, 19 Jul 2010 19:53:54 +0200, Eef Hartman <E.J.M.Hartman(a)tudelft.nl> wrote: >Sylvain Robitaille <syl(a)alcor.concordia.ca> wrote: >> This all suggests, however, that perhaps the scripts at Slackbuilds.org >> don't explicitly set a umask, and I would argue that this is an >> oversight that should be corrected. > >Actually, neither do all of the build scripts in the source tree of >Slackware itself. They all depend on the "as distributed" root environment. Yes, that was the point I was trying to make, but Sylvain likes to modify his root environment -- difference is, Sylvain can see what needs to be done in that modified environment to build install packages. > >Look i.e. at the build script for the libtiff update I quoted >earlier: >slackware-13.1/patches/source/libtiff/libtiff.SlackBuild > >PS: I must correct myself on that previous message: tar _as root_ >will create the dir owners and atributes correctly WHEN they are >correct in the .txz (cq .tgz for releases 12.x and earlier) package, >the root's umask will only be applied to any files, created in the >doinst.sh script. Reminds me of another old argument about extracting kernel tarball as root, odd things may happen... So one works as user on the kernel source, calling up the root account only for the install steps. At least is that case I have the words from Linus to explain the rationale :) Slackware's known default root environment is not hard to comply with, and then it's up to the operator to be aware of what they're doing when building packages in non-default environment. Have we stomped this thread to death yet? :) Grant.
From: Dario Niedermann on 19 Jul 2010 18:59 Eef Hartman <E.J.M.Hartman(a)tudelft.nl> wrote: > Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: >> 1. the simpler solution: installpkg knows a list of untouchable system >> directories; these will never be extracted from the tarballs, only >> their contents will; > > Won't work for a first install as aaa_base actually has to CREATE all > those "untouchable" directories, even when already there! > The name has been chosen so that IT will always be installed first. <slrni3tjpv.qib.M8R-cthw2f(a)7252d9cf.at.gmail.com> 1st paragraph <slrni40hn9.65s.M8R-cthw2f(a)7252d9cf.at.gmail.com> <slrni40vb6.65s.M8R-cthw2f(a)7252d9cf.at.gmail.com> last paragraph > But Pat will never change installpkg that way Are you an appointed spokesperson? > so if you want that, go to another distribution! Switching distro as soon as you don't like some implementation detail is for wannabes. I'm staying with Slackware because I can hack it to my own taste. -- > head -n1 /etc/*-{version,release} && uname -moprs Slackware 12.2.0 Linux 2.6.27.31-smp i686 AMD Turion(tm) 64 Mobile Technology MK-36 GNU/Linux
From: Sylvain Robitaille on 19 Jul 2010 23:06 Eef Hartman wrote: >> This all suggests, however, that perhaps the scripts at Slackbuilds.org >> don't explicitly set a umask, and I would argue that this is an >> oversight that should be corrected. > > Actually, neither do all of the build scripts in the source tree of > Slackware itself. They all depend on the "as distributed" root > environment. The primary difference here is that when used to build the distribution, the build environment is *known* to conform to what is required by the scripts. The scripts, then, are (arguably) really a form of reference documentation. This is not so with the slackbuilds.org scripts. That said, I think the Slackware source scripts also could stand to gain from the proposed improvement, and in fact was modifying them accordingly back in 10.0 days when I was working on my Alpha port. I never finished the port, so my mods were never offered back as a contribution. -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)encs.concordia.ca Systems analyst / AITS Concordia University Faculty of Engineering and Computer Science Montreal, Quebec, Canada ----------------------------------------------------------------------
From: Sylvain Robitaille on 19 Jul 2010 23:12
Grant wrote: > Reminds me of another old argument about extracting kernel tarball as > root, odd things may happen... In nearly 15 years of using, and working with Linux, and building custom kernels quite frequently during those years, I've never encountered any such problem, and I've always unpacked the kernel source tree as root. > Slackware's known default root environment is not hard to comply with, > and then it's up to the operator to be aware of what they're doing > when building packages in non-default environment. True enough, but what's proposed is a simple change that can make scripts less prone to unintentional behaviour in unknown environments. Wouldn't you want your own scripts to be robust? What if you published scripts for public distribution, to be used in unknown environments? -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)encs.concordia.ca Systems analyst / AITS Concordia University Faculty of Engineering and Computer Science Montreal, Quebec, Canada ---------------------------------------------------------------------- |