SEO

I am using Gentoo. I would like to replace some of my core files with
custom built alternatives. For example, I would like to replace
/bin/echo, /bin/ls, and lots of other base binaries.

Is there a way to lock these files out of the portage database,
preventing them from ever being overridden by portage.

Also, I would like to replace /etc/passwd, /etc/group, etc/shadow,
/etc/gshadow, and other key configuration files.

Is there a way to prevent these from being updated by portage?

Thanks in advance to anyone who can help.

Mark.

--
Mark Hobley,
393 Quinton Road West,
Quinton, BIRMINGHAM.
B32 1QE.

On Fri, 09 May 2008 21:08:15 GMT, Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:
>I am using Gentoo. I would like to replace some of my core files with
>custom built alternatives. For example, I would like to replace
>/bin/echo, /bin/ls, and lots of other base binaries.

>Is there a way to lock these files out of the portage database,
>preventing them from ever being overridden by portage.

>Also, I would like to replace /etc/passwd, /etc/group, etc/shadow,
>/etc/gshadow, and other key configuration files.

>Is there a way to prevent these from being updated by portage?

equery belongs <file> to find what package has them
then put the package in /etc/portage/profile/package.provided


>Thanks in advance to anyone who can help.

>Mark.

Mark Hobley wrote:

> I am using Gentoo. I would like to replace some of my core files with
> custom built alternatives. For example, I would like to replace
> /bin/echo, /bin/ls, and lots of other base binaries. [...]

Just for the record, */bin/echo,* */bin/ls* and siblings are normally never
used if you're running GNU Bash as your command shell, because Bash has
those commands built-in.

These commands only exist as independent binaries for when you're running a
shell that doesn't have those commands built-in, like the very
minimal /ash/ shell, once popular on small-memory systems.

Just a FYI... ;-)

--
*Aragorn*
(registered GNU/Linux user #223157)

On Saturday 10 May 2008 13:23, Aragorn wrote:

>> I am using Gentoo. I would like to replace some of my core files with
>> custom built alternatives. For example, I would like to replace
>> /bin/echo, /bin/ls, and lots of other base binaries. [...]
>
> Just for the record, */bin/echo,* */bin/ls* and siblings are normally
> never used if you're running GNU Bash as your command shell, because Bash
> has those commands built-in.

Well, ls is not a built-in. As for echo, many scripts explicitly
hardcode /bin/echo to avoid breaking when run under a shell that does not
have echo built-in (ok, echo should not be used and printf should be used
instead, but that's another story).

pk <pk@pk.invalid> wrote:
> On Saturday 10 May 2008 13:23, Aragorn wrote:
>
>>> I am using Gentoo. I would like to replace some of my core files
>>> with custom built alternatives. For example, I would like to replace
>>> /bin/echo, /bin/ls, and lots of other base binaries. [...]
>>
>> Just for the record, */bin/echo,* */bin/ls* and siblings are normally
>> never used if you're running GNU Bash as your command shell, because
>> Bash has those commands built-in.
>
> Well, ls is not a built-in.

That depends on the shell. ls is a built-in for tcsh, at least (it can be
excluded in the build options, or by environment variables).

> As for echo, many scripts explicitly
> hardcode /bin/echo to avoid breaking when run under a shell that does
> not have echo built-in (ok, echo should not be used and printf should
> be used instead, but that's another story).

There are two different and slightly incompatible families of "echo" -- the
SysV family and the BSD family. The former supports escape sequences with a
backslash, and the latter has more command line options. GNU tries (and
fails) to be a mix of both, by allowing some of the escape sequences when
using the -e command line switch. Needless to say, that doesn't make it
compatible with SysV echo sequences.
The use of full paths is done both to avoid using a built-in, and to get the
right version where both commands exist on the same system (on several
commercial unixes, you often find the SysV variant in /bin and the BSD
variant in /usr/ucb).
Setting ECHO to the version you want means a single line change near the top
of the script, and you can continue to use the escape codes or switches
everywhere else in the script, as long as you call $ECHO instead of echo.

As for printf, you do NOT want to use that if compatibility is a main
concern. You might as well require bash or ksh then, cause you will be
incompatible with lots of older systems (including many legacy[1] commercial
unixes) which lack printf.

[1]: With "legacy" meaning "something that works", and thus won't get
upgraded or replaced unless it's absolutely necessary. Lack of "printf"
won't make an IT manager pay big bucks to upgrade and risk an important
working system getting serious downtime.

Regards,
--
*Art

On Saturday 10 May 2008 17:15, Arthur Hagen wrote:

> As for printf, you do NOT want to use that if compatibility is a main
> concern. You might as well require bash or ksh then, cause you will be
> incompatible with lots of older systems (including many legacy[1]
> commercial unixes) which lack printf.

I was speaking of posix systems, which imho is the only reasonable reference
when speaking of "compatibility" or "portability" when no additional
information is known. And, as you pointed out, "echo" does not have less
problems either. Its advantage is that it's more likely to be present in
legacy systems, you are right on this.

Anyway, the OP has no such problems, since he's using a Gentoo system.

> [1]: With "legacy" meaning "something that works", and thus won't get
> upgraded or replaced unless it's absolutely necessary. Lack of "printf"
> won't make an IT manager pay big bucks to upgrade and risk an important
> working system getting serious downtime.

Ah well, I surely agree with this, but that cannot be guessed by just
reading a message in a newsgroup :-)
As I said before, lacking other information, I tend to suggest using more
posix-standardized features. Nonetheless, I agree that in most cases you
can be correct.

Regards

In alt.os.linux.gentoo AZ Nomad <aznomad.3@premoveobthisox.com> wrote:

> put the package in /etc/portage/profile/package.provided

Looking at my /etc directory, I notice that my package.* files are
located in /etc/portage as follows:

/etc/portage/package.keywords
/etc/portage/package.mask
/etc/portage/package.use

There is no subdirectory /etc/portage/profile/

Googling around, I find references to both /etc/portage and
/etc/portage/profile.

These files appear in different locations, depending on which
documentation I read. Hence I am confused.

Is it necessary to create a subdirectory "profile"?

Should I relocate my existing files /etc/portage files to a newly
created profile subdirectory, or is /etc/portage ok?

Do I have to modify or update scripts to reflect a change of location?

Please advise.

Mark.

--
Mark Hobley,
393 Quinton Road West,
Quinton, BIRMINGHAM.
B32 1QE.

On Sat, 10 May 2008 13:23:11 +0200, Aragorn propped his eyelids open with
toothpicks and wrote:

> Mark Hobley wrote:
>
>> I am using Gentoo. I would like to replace some of my core files with
>> custom built alternatives. For example, I would like to replace
>> /bin/echo, /bin/ls, and lots of other base binaries. [...]
>
> Just for the record, */bin/echo,* */bin/ls* and siblings are normally
> never used if you're running GNU Bash as your command shell, because
> Bash has those commands built-in.
>
> These commands only exist as independent binaries for when you're
> running a shell that doesn't have those commands built-in, like the very
> minimal /ash/ shell, once popular on small-memory systems.
>
> Just a FYI... ;-)

But if you are using bash, alias your custom commands in .bash_aliases

alias ls='/usr/bin/custom/ls'
alias echo='/usr/bin/custom/echo'
etc...

and in .bashrc

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi


--
Rob - Linux user number 467898 Ubuntu User number 17166
Linux 2.6.22-14-generic
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
665.9238429876 - Number of the Pentium Beast
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

On Sat, 10 May 2008 18:08:05 GMT, Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:
>In alt.os.linux.gentoo AZ Nomad <aznomad.3@premoveobthisox.com> wrote:

>> put the package in /etc/portage/profile/package.provided

>Looking at my /etc directory, I notice that my package.* files are
>located in /etc/portage as follows:

>/etc/portage/package.keywords
>/etc/portage/package.mask
>/etc/portage/package.use

>There is no subdirectory /etc/portage/profile/

>Googling around, I find references to both /etc/portage and
>/etc/portage/profile.

>These files appear in different locations, depending on which
>documentation I read. Hence I am confused.

>Is it necessary to create a subdirectory "profile"?

>Should I relocate my existing files /etc/portage files to a newly
>created profile subdirectory, or is /etc/portage ok?

>Do I have to modify or update scripts to reflect a change of location?


Create a file called /etc/portage/profile/package.provided. Create the profile
directory if needed.

In the file put the package category/name-version

For example, I have a /etc/portage/profile/package.provided with
the lines:
media-libs/libdvdread-0.9.7
media-video/transcode-1.0.6_rc2


It causes gentoo to think those packages are installed even though portage
didn't do it. If at some later date a newer package is required as a dependancy
such as a transcode-1.1.0, then portage will bitch and I'll have to manually
install a newer version (probably already done) and update the package.provided
file.