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: Grant on 14 Jul 2010 20:23 On Wed, 14 Jul 2010 16:48:05 +0000 (UTC), Mike Jones <luck(a)dasteem.invalid> wrote: >Responding to Sylvain Robitaille: > >> Robby Workman wrote: >> >>> Leave root's umask at 0022, and/or switch to root properly from your >>> user account, and/or manually set umask to 0022 before using one of the >>> build scripts. This is NOT a problem with the scripts, >> >> With all due respect, Robby, I would like to argue that the scripts >> should explicitly set any environment that they require to produce a >> proper package. That should certainly include, at a minimum, the umask >> the script expects to run with (and the PATH environment where any >> commands used should be found). >> >> It isn't at all reasonable for any script repository to dictate what the >> user's "root" environment (including umask and PATH) should be, and it's >> much more efficient and much less error-prone if that is setup in each >> script rather than the user needing to remember to set it prior to >> calling these scripts. >> >> That said, I know that I'm suggesting a large number of scripts be >> modified, but I would ask whether these will perpetually be cast in >> stone, regardless of any errors or oversights that might be found, just >> because of the sheer number of them? I certainly don't believe that is >> the intention, and what's presented here seems to me to simply be an >> easily corrected oversight. > > > >I'm seeing the same logics here. > >No biggie, but something that could be improved. Sure, could be improved, but SBo follow same rules as Slackware, that root environment is known, and Robby W. confirms that. I guess 'they', the Slack team, don't see looking after the not-so-bright user as very important. In my view Slackware is a very good second distro, after one knows about the bad things other distros do to make this sort of thing a whole lot worse. The rpm dependency net that refuses to allow package removal is something Slackware avoids by keeping things very simple. Switching to real root to create packages? I don't like it, but it's what slackware expects and is built on. Didn't somebody use fakeroot to get over that issue? Or some chroot jail? I forget details. Grant.
From: Helmut Hullen on 15 Jul 2010 02:19 Hallo, Sylvain, Du meintest am 15.07.10: > The script that creates the packages should not assume even that it > has root privilege. In more cases than not, the only purpose for > that privilege is so the ownership of the contents of the created tar > file can be predictable. I've tried running "cmus.SlackBuild" (you remember: Dario mentioned that packet as "broken") under a non-root-account: didn't work. Viele Gruesse Helmut "Ubuntu" - an African word, meaning "Slackware is too hard for me".
From: Helmut Hullen on 15 Jul 2010 10:47 Hallo, Sylvain, Du meintest am 15.07.10: >> I've tried running "cmus.SlackBuild" ... under a non-root-account: >> didn't work. > "didn't work" is not a useful report. 168 messages chown: changing ownership of `./some_file': Operation not permitted And "/tmp/SBo/package-cmus" is empty. > I haven't read that script so I don't know where it requires root > privilege. Most require it only for the benefit of "chown", for > which I've already posted the solution I use in my own scripts. That's ok. But Mario has told he had compiled "cmus" and it had produced strange errors - he hasn't yet told how he had worked. I can't reproduce the errors he's mourning about. Viele Gruesse Helmut "Ubuntu" - an African word, meaning "Slackware is too hard for me".
From: Grant on 15 Jul 2010 18:28 On Thu, 15 Jul 2010 19:29:29 +0000 (UTC), Sylvain Robitaille <syl(a)alcor.concordia.ca> wrote: >+Alan Hicks+ wrote: > >> I think you have a valid point, at least for the umask. Setting PATH >> isn't necessarily a bad idea either. Both of these could be added to >> our template without causing any problems that I can foresee. > >Thank you. That's certainly a step towards making your scripts more >robust. > >> With that said, I don't see us going back and changing working scripts >> because after several years of SBo one mental midgit experienced a >> failure caused by his lack of understanding and bitched about it. > >I don't think you should let personal opinions (or the fact that the >person reporting the problem has turned the discussion into his personal >flamewar) interfere with the technical issues at hand. Robby Workman >already pointed out that such an edit could be scripted, thus making it >relatively trivial to fix existing scripts, ensuring that future users >would not run into the same problem. Assuming it really is that simple, >I see no solid reason why you wouldn't go ahead and fix existing >scripts. Otherwise, perhaps all you need is the help of a few trusted >volunteers? > >> Hundreds or thousands of people have used SBo scripts over the past >> years and only this 1 person has ever complained of the problem. > >That may be true. What it does is explain why such a thing could have >been overlooked for so long, though, rather than suggest that the >problem isn't real, or that existing scripts couldn't benefit from the >fix. > >> I just don't see a justification for editing a large volume of >> existing scripts for such a trivial and rare problem. > >Full disclosure: I encountered a similar problem early on in my own use >of (third-party) SlackBuild scripts. I can't recall for sure whether it >was from a script from SlackBuilds.org, one of Robby's, one of Eric's or >"other", but that doesn't matter. It caused me to look for the cause of >the problem at that time, and of course the fix made it into the >template I use for my own scripts. Yes, there were some teething issues, nothing serious enough to make the FAQ? Should something gained from all this flamage be added to the FAQ? > >Now, with all of that said, what SlackBuilds.org does with its existing >scripts is up to the folks that are represented by SlackBuilds.org. I >have no personal investment in the matter, except to hope that by >proposing this fix I've helped make these scripts more usable for more >people in the long term. And to answer something you asked upthread, adding SBo accessories is a bit different from the initial install, because the environment is no longer controlled as it is during the install. I think that's what I was trying to say, when writing about 'real' root login vs the various 'fake' root logins that might cause trouble. Still no fix for broken packages though ;) 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? Grant.
From: Grant on 16 Jul 2010 05:10
On Fri, 16 Jul 2010 04:46:56 +0000 (UTC), Sylvain Robitaille <syl(a)alcor.concordia.ca> wrote: >Grant wrote: > >> Yes, there were some teething issues, nothing serious enough to make >> the FAQ? > >Not that I saw, but if you have text to propose, it certainly should be >considered. > >> Should something gained from all this flamage be added to the FAQ? > >We may end up arguing over what the "answer" to the question should be, >or maybe even how the question should be worded. > >Note that Alan's point comes to mind, that this really has not been a >frequently encountered issue (and therefore not a "frequently asked >question"). Yes, that's what many of us were trying to say early on, 'snot a problem, move on... > >> And to answer something you asked upthread, adding SBo accessories is >> a bit different from the initial install, because the environment is >> no longer controlled as it is during the install. > >I don't recall asking it, but yes, I agree with your point here. > >> I think that's what I was trying to say, when writing about 'real' >> root login vs the various 'fake' root logins that might cause trouble. > >My point was that there isn't anything "fake" or "not real" about >euid=0. You still have root privilege. The idea of "login as root to >get a 'known' environment" implies a decree that one will never change >the default environment of the root account. I don't think that's a >scalable approach. 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? I'm agreeing with you now, where before I didn't see why one would change root post install. > >> I'm trying to remember too, which part of the installer requires that >> old, particular version of tar? > >I'm not 100% sure, but I believe it has to do with the options used in >installpkg when calling tar. I imagine there was some functionality >that was deemed necessary, but had been removed from later versions of >tar. I've not studied the matter, since it has always worked fine as it >is. > >> Or was that issue fixed when the new compression method was added? > >Try this: > > xzcat /path/to/some-package.txz | tar-1.13 tvf - > >That's one of the reasons having "packages" be simple tar files is a >really good thing. :-) Okay, point taken (by inspection ;) Grant. |