Michael Fothergill wrote:
Dear Debianists,
This may be a somewhat dumb question but it might have some merits so I
am going to ask it.
From the postings on the list I have received so far I have learned some
interesting facts about jigdo, Sarge, Etch i386 and Etch AMD64.
I am very grateful to everyone who responded for their time and patience.
I respect this.
If I understand it correctly upgrading from e.g. A Sarge DVD to Etch is
with jigdo is pretty much pointless because there is so little overlap
of common files between the two releases.
I seem to have confirmed this myself in practice when I scanned the two
DVDs of Sarge 3.1 r4 under jigdo having read in the jigdo file for Etch
RC1 CD image number 1.
I only found 23 or so files on both DVDs that were common to the 1200 or
so files that jigdo says comprise the first CD image of Etch RC1.
So I have dumped the idea of bootstrapping an Etch RC1 download with
jigdo and my Sarge DVDs. It is a non starter.
However, it does seem as though Etch AMD64 does share a reasonable
number of files in common with Etch i386.......
My new question is this:
If you look on the Debian installer page you see that distributions of
the OS for a variety of different architectures exist:
[alpha] [amd64] [arm] [hppa] [i386] [ia64] [m68k] [mips] [mipsel]
[powerpc] [sparc] [s390]
My question is this:
Ok I'll have a stab at this :)
What degree of common files would exist between all or certain sub
groups of these different architectures?
As per my previous response the *all.deb are architecture independent.
Would there be enough in either all of them or a subset that it might
make sense to make a separate downloadable common iso file image or
jigdo file set that you could downnload from one common server address
and then get only the extra files needed to make up the entire
distribution for the each specific individual architecture from its own
server site address?
This all depends on what people are downloading. Over the entire
package repository probably, but based on downloading the first 1 or 2
cd's, the netinstall etc. there may not be enough commonality to
justify this.
If so would this not save on server space allocation and download time?
AFAIK, the file actually only exists in one location, the package
list/template that you download tells apt/aptitude/jigdo etc where to
find the package on the server.
As for download time, it may save some if you are installing across
multi-arc in the same network/environment but given the number of
packages in a common install ( I have 334 in my apt-cacher directory and
use a pretty full kde desktop environment ) its unlikely to save all
that much IMO.
My other question this is this.
Is the reason that the number of common files to be found when comparing
the Sarge 3.1 release of Debian and e.g the Etch RC1 is very low a
function of the fact that huge changes have been made across the OS?
Yes that's progress :) There has been a change in the C++ api (I think)
so the majority of the packages have to be recompiled to match this.
Or is it that the underlying contents of a lot of files is identical to
those found in Etch but they have been given different names or small
changes have been made to them such that they are not absolutely
identical any longer?
See above
Is it possible that Lenny could be written in such a way as to maximise
the reuse of identical files from the point of jigdo that are used in
Etch in such a way as not to undermine the innovative progress and
develolpment of Lenny?
This is more about jigdo/cd templates than development of lenny I think.
Could all the architecture releases of Lenny be designed to make maximum
use of jigdo in the ways I am describing or would it be a beaurocratic
nightmare or a waste of time with no benefit, or worse would it cock up
and interfere with the development of Lenny?
I am not a DD and don't know how difficult it would be to create the
CD/DVD sets in the different ways you describe, but it may be worth
investigating further.
If you think this a garbage idea feel free to say so.
I don't mind.
Not at all.
Regards
Michael Fothergill
_________
Wackojacko
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
