Support wrote:
> Mike McCarty wrote:
>> That's what I mentioned in the first message, which I didn't make
>> clear, I guess. In between Chapters 5 and 6, one would
>> build & install in /tools a temporary copy of the manager. Then, after
>> the initial setup in Chapter 6, the first package built & intalled
>> would be the package manager itself, using the temporary copy in
>> /tools to install the permanent version into the chroot environment,
>> that is, into what will eventually be the permanent system.
>>
>> Mike
>>
I see now that there are actually two somewhat related
issues here, which I'm conflating. One is that the PM
never gets put under its own control, ever, and the
other is when the PM gets put under its own control.
It might be easier (see below) for various PM techniques
to defer placing the PM under its own control (doing an
actual install as opposed to placing it into /tools
somewhere where it can be run) until later in Chapter 6
than at the very beginning, and you seem to be addressing
this.
The other is, that with the Hints I've been reading, the PM
never actually gets installed, that is, placed under its own
control, it just gets stuck into the PATH where it'll get
executed on an as needed basis. This doesn't seem right, somehow.
If ping is so important that its version needs to be tracked,
then isn't the PM even more important? (If you believe in PM
at all, that is). I think that one would want the PM under
control so that versions could be checked, changes noted,
appropriate back-outs designed into it, etc. In other words,
it could be managed as a package, rather than just a bunch
of executables, data files, and directory structures, and could
be uninstalled and a fall back to a previous version could
be done, if needed, etc.
> I see your thinking, but in theory (following the dependency tracking
> malarky) you can't install the package manager first in chapter 6,
> because the package manager would have dependencies of its own which
> must be satisfied in order to install the package manager (yep, its a
> headache). So:
However, the specific package manager I have in mind is the Package
User package manager, which (AFAICT) has all its dependencies already
satisfied (except for su, which the hint describes how to put in there).
> Chapter 5, build entire toolchain
> End of chapter 5, build deps for package manager and then the package
> manager itself
[And place it into /tools, using any convenient technique (package
management not necessary in the temporary build).]
> Chapter 6, build packages of each section, in the order they appear in
> the book, then install each package after you've built it
You mean install it using the temp package manager in /tools, I suppose.
> As for when you build the package manager for the final system, you
> could do this at any point in chapter 6 where the deps of the package
> manager have been satisfied, however, as you still have access to the
Our thinking on this matter coincides, except that AFAICT the Package
User tool set is a collection of scripts, and the only unfulfilled
dependency I know of is su, which is easily put into the /tools
location during Chapter 5. Other package managers might have more
dependencies, which might not be met. In that case one has three
options, I guess
defer installing the package manager until all deps are met
and just use the temporary tool in /tools until that happens,
then build and install the "real" PM, and use it from then
on
make sure to build all dependencies the PM has in Chapter
5 and install them into /tools, then use the PM in /tools
to do the install, using a --forced install, and use the
"real" PM to do all the other installs
"fake" an install by hand
However, the Hint for Package Users never puts the PM under the control
of the PM, ever. In fact, I don't seem to recall any of the Hints
covering this topic, that is, placing the PM under its own control
so its versions can be tracked, upgrades performed, etc.
> one in the toolchain, I'd see no advantage of working out when its best
> to do this, I'd just finished chapter 6 and then build my package manager.
In any case, ISTM that even when the package manager has other
dependencies, they could be built in Chapter 5 into the /tools
area, and then it could still be the first thing run. However,
even whenever the package manager gets built, it should be used
to do its own install. That requires two installations, as do
other parts of the tool chain, and ISTM that is best handled
by building the deps (if any) in Chapter 5.
If the package manager tracks dependencies, then the first install
would have to be a --forced install, so that, even if its dependencies
are not met, the /tools version would still install the permanent
version.
Anyway, eventually the package manager should be under the control
of the package manager, and for Package Users that seems to me
to be particularly easy to achieve.
> Hope thats clearer, I was a tad sleepy when writing my previous
> messages, so apologies for that.
Oh, no problem. I'm just trying to understand why the PM never
winds up under the control of the PM, and why that can't easily
be done as the first install in Chapter 6.
Of course, for those who just "do it all in their heads", this
is a pretty silly discussion. However for those who really do
feel the need for a PM, not having the PM under control seems
kinda weird.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
