On Thursday 20 September 2007, Mike Frysinger wrote:
no, this cannot live in baselayout (the package that creates /root/), because
it cannot be run everytime a user upgrades the baselayout package. no, it
cannot be tied to USE=build (used to make stage1) or USE=bootstrap (use to
make
is started, bash reads and
executes commands from ~/.bashrc, if that file exists. Is that really
the intention here? To break upstream-defined behavior?
- John
Alin Năstac wrote:
John R. Graham wrote:
Why can't the simple little default
.bash_profile from /etc/skel be put into /root
Mike, I agree. But, the file that _must_ exist isn't ~/.bashrc but
~/.bash_profile. That's where the that particular bit of
man-page-defined behavior is implemented. If ~/.bash_profile doesn't
exist, then ~/.bashrc won't be sourced whether it exists or not.
- John
--
[EMAIL PROTECTED] mailing
Andrew. Sorry 'bout the top posting; won't do it again. For the rest,
please see my reply to Mike Auty on the same topic.
- John
--
[EMAIL PROTECTED] mailing list
Renat Golubchyk wrote:
That's wrong. Quote:
When bash is invoked as an interactive login shell, or as a non-inter-
active shell with the --login option, it first reads and executes com-
mands from the file /etc/profile, if that file exists. After reading
that file, it looks for
Roy Marples wrote:
Looking over the bash man page, I cannot see the word recommended
anywhere near .bash_profile. Could you clarify where you think bash
recommends this?
Thanks
Roy
Why, sure. It's my interpretation, but a reasonable one, I think. It
recommends it in its
Roy Marples wrote:
No it's not. bash does not recommend anything of the sort. It just
states what files are optionally used during initialisation.
What I'm driving at is that you're making claims that things are broken
or recommended when in fact they are not. Try reading some RFC's and
then
On the forums, I've seen the question, Why isn't my .bashrc being
executed when I log in as root but is being executed when I log in as a
normal user?, asked half a dozen times on the forums. Heck, I even
asked it myself a few years ago. Now, two years later, from a slightly
more mature level of
Andrew Gaffney wrote:
When catalyst builds a stage tarball, it doesn't add any additional
files. All files in any stage tarball are created by one of the
packages contained within. In order to do this, a package such as
baselayout would have to install the file.
Looking at my local
Mike, that exploit is neither easier nor harder if a default
.bash_profile exists. Or, am I missing something?
- John
Mike Doty wrote:
John R. Graham wrote:
like sys-apps/miscfiles. But where it should or shouldn't come from
doesn't answer the fundamental question, Shouldn't
Marijn Schouten (hkBst) wrote:
AND is already the implicit combinator. Thus simply listing both these
atoms
gives what you want:
=some-cat/foo-4.0
some-cat/foo-4.3
Still a special syntax for ranges seems like a good idea. If only portage
would not upgrade past such specifications (and
On 6/15/07, Vlastimil Babka [EMAIL PROTECTED] wrote:
Syntax shouldn't repeat package name twice. It wouldn't make much sense
to use it with =some-cat/foo-4.0 some-cat/bar-4.3 would it?
There's been bug 4315 for ages, so maybe just reassign it to PMS?
I was thinking about AND dependencies
I occasionally run across a package version dependency issue that cannot
be elegantly solved by the current dependency syntax. Every time I've
come across this, it's boiled down to a range. For example, package
some-cat/foo has the following versions in the tree
some-cat/foo-4.0.0-r2
13 matches
Mail list logo
