[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
Mike Frysinger wrote: we should really rename build to stage1, bootstrap to stage2, and then have catalyst add USE=stage3 during the stage3 step ... that would allow packages to automatically key off of the environment That sounds clean too. You could use install to make the transition painless (unless someone just added that USE flag, or it's not politically-correct ofc.) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
Chris Gianelloni wrote: On Fri, 2007-09-21 at 17:45 -0400, Mike Frysinger wrote: the compromise is simple: catalyst runs --config at the end of stage3 for appropriate packages, but as to what those things actually do is left in the ebuilds. I've already stated my preference for not doing *anything* outside of merging packages in the stages. With respect, this is a little confusing. I didn't get past the learning curve for catalyst, but it's clearly not the same as simply merging packages, or you wouldn't need a special tool. Were this stage3, I wouldn't care. Anyway, I'd much rather leave everything as it is now than add the emerge --config stuff. You're free to add it to the ebuilds, of course, which would satisfy the people that want it, but I would prefer not add it to the stages, even if it is documented in the Handbook, as it isn't required. Basically, I'd rather we either throw it into the earlier stages, or not do it at all. You've given good reason on why, while technically feasible since we're only caring about bash at this time, it is still a bad idea as it opens us up to yet another slippery slope. I completely see your point, which is why I'm taking the stance that things are best left as they are now. It seemed to me that a clean, *simple* solution which would work for any future packages that might also need this functionality was proposed. Why not just use it? It's only one command, and the standardisation would mean users could rely on the mechanism for system recovery. Or am I missing some deeper technical implication? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
On Sat, 2007-09-22 at 08:01 +0100, Steve Long wrote: I've already stated my preference for not doing *anything* outside of merging packages in the stages. With respect, this is a little confusing. I didn't get past the learning curve for catalyst, but it's clearly not the same as simply merging packages, or you wouldn't need a special tool. The tool does things like setting up the chroot. The code run by catalyst to get a stage3 from a stage2, not counting things like chroot setup, is emerge -e world just like going from a stage2-stage3 by hand. Anyway, you don't really need to understand it, as I do, and vapier does. If you're really interested, learn a bit about catalyst. Uninformed opinions help no one. It seemed to me that a clean, *simple* solution which would work for any future packages that might also need this functionality was proposed. Why not just use it? It's only one command, and the standardisation would mean users could rely on the mechanism for system recovery. Uhh... what does adding emerge --config have to do with catalyst? There's nothing stopping vapier/anyone from adding the emerge --config steps to the ebuilds. I simply said that I'm not wanting to add code to run those to catalyst for the reasons I have already stated. In no way does that impact the usefulness of the config code for end users. It only affects what goes into the stages. Or am I missing some deeper technical implication? Yup. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
On Friday 21 September 2007, Duncan wrote: Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 20 Sep 2007 12:34:41 -0400: we know that someone taking a stage3 has never configured anything before and so we can safely put defaults into /root/. Just to point out... I've seen people mention overlaying a stage-3 on an existing installation for recovery reasons, generally broken gcc or (on amd64) switching back to multilib from 64-bit only profiles, so it /cannot/ be rightly assumed that there's not an existing configuration in /root/. (Whether that's the right way to accomplish such recovery isn't the point; the point is, it's done, by people desperate to get a working system once again who know no other way to do it.) there's a ton of other files that'd get blown away (like everything in /etc) ... anyone who blindly unpacks a stage3 onto their system gets what they deserve in my eyes Chris's idea of testing both USE=build *AND* that there's no existing file there that's going to get blown away, sounds reasonable, regardless of the debate over where the code is eventually placed. except that doesnt address the issue you raised above at all ... the files are going into /root/ ... how they get there is the subject of the debate -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 21 Sep 2007 03:16:49 -0400: On Friday 21 September 2007, Duncan wrote: Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 20 Sep 2007 12:34:41 -0400: we know that someone taking a stage3 has never configured anything before and so we can safely put defaults into /root/. Just to point out... I've seen people mention overlaying a stage-3 on an existing installation for recovery reasons[.] (Whether that's the right way to accomplish such recovery isn't the point[.] anyone who blindly unpacks a stage3 onto their system gets what they deserve in my eyes Agreed, but I was trying to stay strictly on target and not go there (thus the whole whether that's the right way to do it is beside the point thing). I was/am just pointing out that the base assumption isn't always correct. If the policy is to be the you do it, you get to keep the pieces concept, great, but that's rather different than pretending it won't happen. I'd still rather not see anything going into /root based on principle, but the only at stage-build time, and if there's something there, don't overwrite it is IMO a reasonable compromise. (That's quite apart from the question of what package gets the privilege of dealing with it; I've no dog in that fight to have an opinion on.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
On Fri, 2007-09-21 at 04:23 +, Duncan wrote: Just to point out... I've seen people mention overlaying a stage-3 on an existing installation for recovery reasons, generally broken gcc or (on amd64) switching back to multilib from 64-bit only profiles, so it /cannot/ be rightly assumed that there's not an existing configuration in /root/. (Whether that's the right way to accomplish such recovery isn't the point; the point is, it's done, by people desperate to get a working system once again who know no other way to do it.) Anyone doing anything like this deserves all the suck that comes with it. If some file gets overwritten on their system, so be it. It's not our job to hand hold when people are doing things that are pretty stupid to begin with when anyone with sense would be sure to --exclude things they know they won't want (like /root)... ;] Chris's idea of testing both USE=build *AND* that there's no existing file there that's going to get blown away, sounds reasonable, regardless of the debate over where the code is eventually placed. Thanks, but if the maintainers don't want to do it, there's not much we can do about it. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
John R. Graham [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 20 Sep 2007 07:18:46 -0400: But, hasn't anyone realized that bash is _broken_ if this file doesn't exist? Quoting from the upstream-provided man page, When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. Is that really the intention here? To break upstream-defined behavior? ... if that file exists. IOW, it doesn't /have/ to exist, and for root, many prefer it /not/ exist. But in any case, as mentioned by others already, (human user) home dirs shouldn't be touched by ebuilds (or stages), and /root is exactly that, a (human user) home dir. Home dirs are the domain of the local users and (particularly for /root) sysadmins, not distribution packages (or stages). If the sysadmin wants a /root/.bashrc, it's naturally his privilege and responsibility to create and maintain it according to his needs/preferences. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
Chris Gianelloni [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 20 Sep 2007 09:19:31 -0700: While I would normally agree, there's nothing wrong with having sensible defaults. After all, we install a bunch of stuff into /home/$user thanks to /etc/skel, so how is this different? The big distinction (other than the privilege one) IMO is that putting things into /etc/skel isn't directly inserting them into a live user's home dir. There's a level of indirection, such that live users don't have their live environments interfered with, and such that there's a chance for the admin to review things if desired, before actually acting on anything in skel in terms of setting up a new user. IOW, a direct comparison would be if we setup something like /etc/rootskel/. Of course, that's not quite a correct parallel either, since it's not often that a new root user appears =8^P, but the point I'm trying to make by drawing the parallel should be obvious. Matter of fact, I'd rather /etc/profile was handled a bit more indirectly as well, say treating it much like /etc/make.conf, creating make.conf.example if the file already existed, or like the /usr/share/ baselayout/* files, as I handle the system profile rather differently here too, but that's a somewhat different argument as it's existing behavior (to some extent addressed with etc-update, but one could say so was fstab). At least we can avoid creating further problems of the sort we're avoiding with the above *.example and baselayout/* cases, however, as the current proposal would IMO do. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 20 Sep 2007 12:34:41 -0400: we know that someone taking a stage3 has never configured anything before and so we can safely put defaults into /root/. Just to point out... I've seen people mention overlaying a stage-3 on an existing installation for recovery reasons, generally broken gcc or (on amd64) switching back to multilib from 64-bit only profiles, so it /cannot/ be rightly assumed that there's not an existing configuration in /root/. (Whether that's the right way to accomplish such recovery isn't the point; the point is, it's done, by people desperate to get a working system once again who know no other way to do it.) Chris's idea of testing both USE=build *AND* that there's no existing file there that's going to get blown away, sounds reasonable, regardless of the debate over where the code is eventually placed. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
