[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: general question about jigdo, OS architectures and server load/space....



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



Reply to: