Re: Building boot images with boot-floppies on PowerMac
#include <hallo.h>
* debian@computerdatasafe.com.au [Sat, Jun 28 2003, 11:16:30AM]:
> The "arch maintainer" for what? My problem is with b-f, according to
> those documents you mention, this list is the right place.
For the problem with your powerpc kernel package which was your initial
problem.
> > > > whereever it now are, it is the location of the supplementary packages
> > > > like kernel-image-*; they are still located in unstable while the
> > > > build scripts look in Woody.
> > >
> > > Why is that? I would have thought it logical to distribute b-f configured
> >
> > Because we need a controllable way to take the _stable_ packages for
> > _stable_ branch of boot-floppies.
>
> My initial problem is that that is precisely what I cannot do. If I can
And that is, precisely, and edge and chicken problem. The build cannot
take the kernel images since they are not in the archive, but it uses
the archive structure to decide which package to take (expecting
"stable" package). And the packages do _not_ land in the stable branch
immediately because the distro is frozen. So you stuff _will_ be
buildable when r2 has been released and the SRM accepted the
kernel-image* and according pcmcia-modules-* packages to stable. Until
this happens and since you are using a development version of
boot-floppies (*), please stop fighting windmills.
(*): or an outdated/wrong version, bug FTP maintainers, and this is
another story
> do that, then I have a base to work on.
As said, your work won't be honored enough.
> > > Something needs to be done in the short term. From what I've seen there
> > > are quite a few refugees from Red Hat come to Debian recently. A lot of
> > > them are capable at what they do (installing and configuring Linux), and
> > > they will be finding this part of Debian a nasty shock.
> >
> > Who are you speaking for? Newbies? They are users, not developers.
>
> I am a user. I'm one of many who's been using Red Hat Linux for years
> (in my case since some time in '96), who's been helping out on the
> various Red Hat support lists, and who doesn't like recent changes to
> Red Hat's business model.
Fine. Comming back to your mkisofs example, it's typical daily job for a
normal user to recompile mkisofs again and again?
> > > > Why /etc? We are just building a package, the changes on the host system
> > > > should be minimal.
> > >
> > > At this level, b-f is a tool, not so different from mkisofs, that takes
> >
> > Loool. And KDE is just a user tool, not so different from cdrecord (in
> > your categories), isn't?
>
> Certainly, it's tool, but I don't see that it has much similarity to
> cdrecord;-)
Oh, please, you tried to escape the correct answer.
> > > data from various sources, processes it in magical ways, and produces
> > > outputs.
> >
> > There is not magic in mkisofs, clean code based on almost clean specs.
> > The job ob BFs is quite different. (and before you start bichting: I am
> > the cdrtools comaintainer).
>
> I think you're concentrating on differences, I see similarities. As a
I do not concentrate on anything or close my eyes, I just tell you the
facts. Please estimate the level of complexity in the cooperation of
different tool, platforms specifics, etc.
> user, I don't care for specs, I care for results. Both take some data
There won't be any results if you break with the roots.
> (files), fiddle round and create files containing essentially the same
> data structured differently.
With this attitude you can argument even for LFS.
> As for you being the cdrtools comaintainer, that doesn't carry much
> weight: I have used mkisofs and cdrecord, I know what they do. I don't
> care how they do it, though you might;-)
I did not say cdrecord. It was your idea to distract from the
KDE-vs.-single-tool argument.
> > > I've not tried using it except as root - in my environment the usual
> > > advice not not be root doesn't seem so sensible - but it does require
> > > configuration, and /etc seems to me a sensible place for that
> > > configuration.
> >
> > And if a developers wants to commit the changes on his personal files,
> > he has to move it first? Sounds more like a cludge for me.
>
> I don't understand what you're saying here.
Doesn't matter.
> > Redhat does not have multiple kernels (does it?), so many installation
> > ways withing the first stage installer, etc.
>
> Red Hat has many kernels for IA32. I'm not sure what the latest
Yet another distraction. How many do you select when starting the
installer?
> I've seen
> i386
> i386-BOOT
> i586
> i586-smp
> i686
> i686-smp
> i686-enterprise
> athlon
> athlon-smp
> athlon-enterprise
We have a similar set of kernels, the user is free to install them.
After the base system and the installation kernel has been installed.
> RHL is also available for other architectures, to be sure not as many as
> Debian.
YEAH! And exactly here is the problem. Redhat supports only the "new"
architectures which don't create much trouble.
> If I were to install Red Hat Linux on my Athlon, Anaconda (Red Hat's
Maybe. We have this idea too and I think the D-I people wanted to
implement the automatical selection too. Please consider that the B-F
development has been stopped one year ago. There is no progress, and it
was not a fun to convince the conservatives even to allow the bf2.4
installation flavor to be included, since kernel 2.4 was extremely
unstable 1.5 years ago.
> installer) would choose the athlon kernel. If ran an Athlon-MP, then it
> would install the athlon-smp (I think as well).
I do not think so. It may be possible, but only with a kernel patch
since the normal kernel does not display the SMP capabilities when you
are running a non-SMP kernel.
> It will also install the i686-optimised GLIBC.
686 optimised compilations are food for marketing people. In fact, the
average performance gain is about 5 percent.
<removed the list of fame for RHs autoselection of kernel and libc on x86>
> This is all using the same configuration file, the same installation
> media.
As said before, the things are easy if you do not care about nasty
things like compatibilities (cross- and backward) and a bunch of other
architectures.
> A Pentium II Celeron 733 system I timed took about 15 minutes to create
> a desktop system with KDE as the default desktop, all updates applied.
Use KNOPPIX and you get it faster.
> All I did was boot from floppy, remove floppy when booted. In this case
Then you are lucky. There are also lots of lucky Debian users that
installed it with two floppies. In 15 minutes, with running X. It does
require a bit more knowledge about hardware, but you can get it. Debian
is not for newbies from the sort of plug-and-play Windows users.
> > > Even if you disagree on /etc, ~/boot-floppies/ remains a good place for
> > > personal customisation.
> >
> > WHY? We are developers, not users. We can use diff, patch and cvs.
>
>
> Becase b-f is a tool for users? Shouldn't I want to make customised
You use a tool. You don't compile it daily, see above. Why do you need
customised boot-floppies?
> floppies? Should I have to hack the code to do so?
Yes. And when you do, you have to know what you are doing. I think, D-I
will be the perfect toy for you. Use it, and stop bitching about
boot-floppies.
> > > diagnose that my car won't start, and I don't care whether it's because
> > > it's out of fuel or the spark plugs are dirty. Either way, the engine
> > > cranks but doesn't start.
> >
> > Talk is cheap.
>
> Let's try to be polite.
I still am.
> Sometimes, a change to one package requires changes to another. IBM
> recognised this back in the 70s, when it divided MVS into numerous
> functional components. A change to one component was not allowed to
> change another; instead there had to be a separately-packaged update to
> the other. It's like a change to the kernel requiring a change to
> e2fsprogs to support a change to ext2.
Use D-I.
> In this case, you have that dependency, but it's not documented (or not
> enforced).
The dependencies in the version 3.0.23 (which was released for Woody but
was not shipped with source, only as installation images) did match when
the distro has been released. It's not my fault when something went
wrong later.
> > > I may be mistaken, but I think that if you changed a line near here,
> > > then my attempt to update from CVS would run into trouble:
> >
> > man cvs | grep merge
>
> The point?
> I've used patch (to apply kernel patches mostly). It requires context to
> fit the changes in, and if the context isn't there the patch doesn't
> fit.
The V in CVS stands for Version. The server has the original version and
cvs tries to preserve the modifications.
> That's a problem the user shouldn't need to address.
That's a problem the user should never come in touch with.
MfG,
Eduard.
--
[ISO/OSI Layer Diskussion]
<weasel> 8 ist politik, 9 ist religion
<waldi> weasel: und wo bleibt der luser?
<weasel> waldi: der wurde wegoptimiert -> weniger fehler
Reply to: