Re: coreutils not installable without extra features???

[Dennis Heuer]

On Wed, 19 Mar 2008 17:24:06 -0600
address@hidden (Bob Proulx) wrote:

> Dennis Heuer wrote:
> > i tried to install coreutils onto a new partition as part of a plain
> > new x86_64 system.
> 
> Thanks for the report.  Bug reports and improvement suggestions are
> always welcome.  However some of your report wasn't clear enough for
> me to understand it.
> 
> Are you trying to bootstrap create a "from scratch" build of
> everything?  Into a completely empty partition?

yes! for about a decade i use distros only as hosts for installation. 
no! only the most neccessary stuff to switch to the new system
early and do the rest on it natively. however, it gets harder because
the minimum install base gets bigger, more interdependend and greedier.

> > i did this from a fedora8 system because my old one
> > is a 32bit system.
> 
> Is this from a 32-bit or a 64-bit host system?  If 32-bit I assume you
> are trying to cross-compile 64-bit binaries from a 32-bit compiler?
> That is certainly possible but rather tedious.  Since 64-bit systems
> are readily available it would be easier to bootstrap from a 64-bit
> system.  If you are doing something different then please explain.

the fedora8 version i use is for x86_64

> > however, the fedora8 system is really more than
> > feature-complete (including compatibility and deprecated stuff) and all
> > the tool packages i installed linked to all of that freeheartedly.
> 
> I think you just said that the system has a lot of libraries that you
> didn't realize were there and the coreutils ./configure found them and
> they were linked into your resulting binaries.  Now the program
> binaries that were installed are looking for libraries that don't
> exist.  Is that correct?

yes!
no! i was shure about the situation but wasn't aware of the coreutils
using this all with no option to stop them. 

> > other packages, like util-linux, at least allowed for disabling this
> > behaviour. coreutils doesn't provide such a --without-extras (or
> > similar) option. this said, i now have a problem with all of the
> > freshly installed coreutils searching for something (libtinfo,
> > libselinux, etc.) when i try to start the plain new system to populate
> > it natively. this is a great problem because the new system should be as
> > small as possible to make stripping dependencies to the parent system
> > as easy as possible.
> 
> > please support a 'plain' installation without extra dependencies.
> 
> Bootstrapping a port from pristine source to a new architecture is not
> something that can be trivially done.  Have you looked at how other
> systems such as the Gentoo and Linux-From-Scratch projects do their
> bootstrapping?  There will be good insight and learning into how the
> process works by studying how others have done ports to new
> architectures before.  And since amd64 is pretty well known and
> one of the dominant architectures most of the underlying work of the
> port has already been done.

i'm not shure about what you're interpreting into my person. the last
ditro i used was a SuSE 5 or so (in the black yewel case, without carton
and nice cover graphics). i'm independent for about a decade now and
know how to install a new system. the point is a different one. the old
coreutils didn't rely on selinux and stuff and worked right out of the
box on a "from scratch" system (such a thing is not existing). the new
coreutils don't. and there is no way to reduce their greediness. i
tried some older coreutils versions but, on fedora8, some function
definitions caused conflicts with posix headers (futimens and others).
so i fell back to the old fileutils and textutils packages, which worked
fine.

> 
> The way that I know that new systems have been bootstrapped is to
> create a small set required utilities that are needed to build the
> next layer of utilities which are needed to build the next level of
> utilities and so forth until it is done.  Eventually one gets to the
> point where they can build full projects directly but initially that
> doesn't work.  A layer of bootstrapping code must be ported first.  It
> reads to me that you are trying to jump in at the very end of this
> process without having done all of the earlier part of the process.

can you please tell me why coreutils is at the end of this process? is
it to install even after openoffice and friends? the coreutils MUST be
there even on the most simple but running and usable linux system
(think of ls, mv and cp.) please get aware of this. coreutils MUST be
installable without all the fancy new dependencies. it MUST also be
installable without compatibility but unneeded stuff like libtinfo.
ncurses installs this only at wish.

> What is your goal in doing this?  If it is simply a from scratch
> system then using one of the other source distributions such as I
> already mentioned would be able to provide you with a fully compiled
> from source system more easily.  They have already worked through the
> bootstrapping problems.  If you simply want an amd64 64-bit system
> then using one of the distributions that support it (all of the major
> ones do now) then I would simply start with a live-boot from one of
> those systems.
> 
> If you are simply trying to learn how this works from an academic
> standpoint that is great too.  Knowledge is always useful.  But there
> really isn't any easy way to support something like this out of the
> box.  If you have specific suggestions on how to improve the
> environment to make this easier for bootstrappers to new architectures
> then please let us know.

this is what i did!

you may mean this all for good. however, it is really not on you to
come as a missionary for distributors. and, bootstrapping is far easier
than you think. the only real problem lies in the dependencies. this
wasn't a real problem some years ago. it only becomes a problem more
and more because "core utils" cause dependencies more and more without
the developers really thinking about what they're doing. please offer a
--minimal-dependencies option.

best wishes,
dennis