Jeroen van Meeuwen wrote:
John Summerfield wrote:
Jeroen van Meeuwen wrote:
John Summerfield wrote:
There exists a problem for those who want both CD and DVD-sized
images. I've just done a census of the computers around here, and
there's a few that have CD drives, not DVD.
Can you try and explain to me how this is efficient given the
ambition to release DVD ISO images and CD ISO images for Fedora 9?
DVD images about 3.5 Gbytes?
therefore CD images about 3.5 Gbytes
My plan
CD images imbedded in DVD images about 3.5 Gbytes
Saving
About 3.5 Gbytes
So, you would want the DVD holding the CD ISO images to replace both the
DVD ISO image and the CD ISO images? That is going to be very nasty in
terms of distribution as one would need a double loop mount for each CD
Is that difficult? I'd not have thought so. I'm sure I've nested loop
mounts before.
ISO image to be able to use the installation media as a resource for
additional package installation, not to mention the inability of Jigdo
to cope with this -which at this point is just a Release Feature I'm the
owner of.
I am sure that when I learned to use jigdo some years ago, that it
didn't actually care how the file's structured, and that it actually
works with tarballs. See http://atterer.net/jigdo/
That said, when the component files are around 650-700 Mbytes, I do see
a problem, a complication.
I see three alternatives:
1. A wrapper that extracts the imbedded ISOs so that they can be rebuilt
individually, then the DVD
2. DVD images are distributed only through .jigdo, and a wrapper script
be provided to build the CD ISOs and then the DVD ISOs.
3. Modify jigdo to look for a new .jigdo in the same location when it
finds an imbedded .iso. users who tell jigdo to download the .jigdo
might not notice anything changed.
Richard Atterer might be interested on working with you on this; surely
Debian has the same problem.
Having another DVD just containing the CD ISO images doesn't really
make sense to me.
I didn't say "Another DVD." The DVD image containing CD images would
be installable.
The InstallMethod for CDROM would become more like installing from
hard disk.
The first CDROM though would need to contain another set of metadata
which makes opening up the actual repository a pain in the ass -you have
mediaid's there, again.
I don't understand.
Say we built a slightly-modified boot.iso.
Say this boot.iso contains all that's needed to install
Fedora/RHEL/whatever. Just not the repos.
Say it has a root directory, /images.
Say this directory _might_ have a collection of ISOs.
If this directory has a collection of .ISOs, then it offers the user the
possibility of installing from it. If the collection is incomplete, then
it allows changing media during the install process, as it does now for
CD installations.
I can think of variations, and this might not be the best, but I can
imagine it working, though it would require a small change to the
current procedure for installing from CD: boot boot.iso, eject, insert CD1.
As an aside, it might also offer the ability to eject the boot.iso and
burn the imbedded ISOs.
Also, I'm confused what is the real purpose. The DVD ISO image you
can loop mount and publish via HTTP/FTP, or use off an NFS share to
install
I had some difficulty doing that, those media URLs break things. There
was some discussion here or on fedora users or test about it, and the
best I could find was to run createrepo above the mount point.
I see the point here and I agree, but in my opinion this is a pungi bug,
as it used to run splitrepo even though the media consisted of a single
disc. As far as I can tell this has been solved in the Fedora 9 pungi,
which would make this a moot point.
The whole thing's at the moot stage:-)[1]
[1] Originally, (Anglo-saxon Britain), a moot was a council of
elders/community leaders.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
