Where has the F10 DVD iso file gone?

Christopher A. Williams chriswfedora at cawllc.com
Thu Jan 1 17:26:13 UTC 2009


On Thu, 2009-01-01 at 03:38 -0800, Mike Cloaked wrote:
> 
> 
> Christopher A. Williams-3 wrote:
> > 
> > 
> > Well - a little good news here. After beating on Revisor most of the
> > afternoon today, I managed to get it to actually create a 64-bit DVD
> > Install ISO! I'm going to try it out on a virtual machine in a minute to
> > see how it does. Next up will be 64-bit live media.
> > 
> > In the meantime, I'm trying to find updated documentation. The Revisor
> > Wiki pages only show stuff through version 2.0.5 while F10 has 2.1 and
> > I've already read through all of that...
> > 
> > 
> 
> Now that sounds excellent - if you could share your steps in getting revisor
> to make a usable DVD iso with the rest of us then I bet it would be truly
> appreciated - and presumably using updated packages that were released since
> F10 release?
> 
> I have been slowly moving in that direction also - documentation is sparse
> and a good tutorial would be hugely valued.

Well - I wish the news was as good as I had hoped...

Revisor did indeed spit out a DVD ISO for me. It even booted and ran an
install in my VM. Unfortunately, what it installed turned out to be
almost completely unusable. I also managed to build a custom 32-bit Live
CD. Unfortunately it was no more usable than the DVD. I think I'm close
though. Next step is to try this using the base F10 kickstart files (now
that I have found a couple of them).

Side Question: Where is the official place the F10 kickstart files are
supposed to be kept? This should be something relatively easy to get to,
shouldn't it?

I have found a few other things about Revisor that should be highlighted
brightly because I've seen the same problems with several other tools
like Yum Extender.

It seems the reason why I can't build 64-bit Live images at all is
because something in the package selection process / tools arbitrarily
includes BOTH the 32-bit and 64-bit versions of everything you select in
the package manifest instead of including just the 64-bit packages if
they exist. This leads to the conflicts that cause the whole thing to
fail. I think the reason it doesn't happen with 64-bit DVDs is because
the selected package RPMs are only added to a specific directory on the
DVD. Live images actually do a system installation as a part of the
build process.

I've also seen this package selection behavior in Yum Extender
(including the current version in F10). At least with Yum Extender, you
can manually de-select all of the non-64-bit packages by hand. It's
incredibly tedious to do, but it works. This also happened in versions
of the package selection tool fka Add Or Remove Programs in F8 and
earlier. Moreover, it also happens with kickstart files created via
system-config-kickstart. I don't know if Package Kit has this problem or
not yet.

Of note, this does NOT happen when trying to build 32-bit systems. The
64-bit packages are (correctly) ignored. It is only when trying to add
package groups to 64-bit systems that the 32-bit packages are also
selected. Since this is something common to several tools, I suspect the
problem is either in something under the covers they all use or it is in
code that they all share.

As to other issues with Revisor, what I'm finding is that a lot of stuff
in the GUI either just doesn't work at all or is just plain broken. It
clearly looks like a work in progress - with a lot of work left to be
done. What I can tell you so far is:

1) Read the doc that does exist. It at least will give you a clue about
how Revisor was intended to work, even if it doesn't exactly work that
way because so much is broken or has been changed since the doc was
written.

2) Develop as good an understanding of what the build process involves
as a part of this so you know what the tools are trying to do along the
way. Believe it or not, the doc on Pungi - sparse as it is - was
extremely helpful to me in understanding more about Revisor.

3) Watch Revisor (and the other tools) closely. Every little error
message will give you clues about things that you might be able to fix
or find work-arounds for in this trial and error process.

Now - back to my original point: I still believe Revisor (along with the
others) has terrific potential. It seems to be about 80% of the way
there in terms of functionality and also needs some major bug fixing. If
I were a coder, I would gladly help with fixing that stuff, but I'm not.
As an Enterprise Infrastructure Architect, I can only help with this
kind of testing and feedback unless you need help with designing the
underlying server and network infrastructure needed to support the
development platforms...

If these fixes can be implemented, we then have a reliable tool for
creating custom spins. With that, we have the ability to begin
automating the technical process for generating monthly ISO updates from
the "gold" kickstart files. All that is then left is to examine and
optimize the process for QA and release such that people who are already
very busy don't have to take on more. I submit that, since the updated
RPMs already have to go through a testing process, what actually needs
to be tested for such an interim respin should be much smaller than a
full release.

If people put their collective brains to this, it should be solvable.

Cheers,

Chris

--
==================================
By all means marry;
If you get a good wife, you'll be happy.
If you get a bad one, you'll become a philosopher.

--Socrates




More information about the fedora-test-list mailing list