Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?

[Mike Frysinger]

On Thursday 20 September 2007, Chris Gianelloni wrote:
> On Thu, 2007-09-20 at 12:34 -0400, Mike Frysinger wrote:
> > > > what catalyst should do is just before cleaning up the stage3 root
> > > > and packing it up is run `rsync -a /etc/skel/ /root/`
> > >
> > > It definitely should not.  One of my primary motivations with catalyst
> > > is to ensure that the users get *exactly* what would be provided by the
> > > profiles/packages.  We don't add extra files into the stages and likely
> > > never will.  Doing something like this in catalyst would create an
> > > inconsistency between doing a stage3 install and any previous stage
> > > installs.  Yes, we don't support stage1 anymore, but we still support
> > > stage1 users once their systems are up and running.  Having them
> > > inconsistent only causes one more area where we have to do extra
> > > troubleshooting to determine the cause.
> >
> > not really ... someone installing by hand and someone taking a default
> > setup are different things.  we know that someone taking a stage3 has
> > never configured anything before and so we can safely put defaults into
> > /root/.  we have no idea what people have done when they run emerge
> > themselves.  that is why only putting this into catalyst makes sense.
>
> I'll respectfully disagree and say again that I won't add anything like
> this to catalyst for the reasons mentioned above.  I see no reason why
> we cannot provide sensible defaults in stages lower than three,
> especially since I want to see everything in ebuild code.
>
> Also, my plan for this would be add the copying of the .bash* files
> from /etc/skel if and only if USE=build *and* the files do not already
> exist, done during pkg_preinst/pkg_postinst somewhere.  This will pull
> it into the stage1 tarball, making it available to everyone on all
> further stages, it keeps it from being done every time someone emerges
> bash, it doesn't stomp on existing files, and it doesn't show up in VDB
> linked to the bash package.  Is this acceptable?

no, bash is not a special case

why not add an `emerge --config baselayout` to the end of stage3 and i'll do 
the /root/ default setup in the baselayout ebuild

> > > Well, it depends on whether we're interested in getting all of
> > > /etc/skel or just the .bash* files.  About the only thing I would see
> > > useful as "defaults" is the .bash* stuff and a .ssh directory.  I do
> > > agree that everything else should be left up to the user.  If we
> > > decided what to include and limited it, it shouldn't be a problem to do
> > > it via USE=build at all.
> >
> > anything that is part of the system /etc/skel/ makes sense (iow, anything
> > that is in /etc/skel/ at the end of stage3).  the files from bash and the
> > .ssh dir are the only things that go into /etc/skel/ right now for the
> > default system.
>
> OK.  So we now know that only bash/openssh would be really important
> here, and the .ssh directory really isn't much of a show-stopper, since
> it isn't populated.  I mention this only because we don't install
> openssh until stage3, so there's no special USE flags in use at that
> time.  If we limited it to bash (and tcsh, etc. for non-Linux) using
> USE=build, it would satisfy this request, one which I personally would
> like to see done, and still not have to change a single line of code in
> catalyst, which also respects my wishes.  It doesn't stomp on user's
> files.  All in all, it seems like a safe enough solution to me.

no ... the fact that *today* we have just bash/openssh and *today* openssh is 
installing an empty dir (not exactly empty, the permissions are set much 
stricter than default `mkdir`) is irrelevant ... i want to fix this once and 
only once and not see another request about XYZ package installs FOO and now 
we decided we also want special code to handle FOO
-mike