Re: general question about jigdo, OS architectures and server load/space....
In article <[🔎] BAY135-F13FE349029E9B2712C776091CA0@phx.gbl> you write:
>
>My question is this:
>
>What degree of common files would exist between all or certain sub groups of
>these different architectures?
There is quite an overlap - all the *_all.deb files are common from
one arch to the next.
>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?
>
>If so would this not save on server space allocation and download time?
Probably not, no - most people only tend to want to download for one
architecture. Also, the files on the CDs and DVDs are deliberately
sorted in dependency and popularity order. This means that many people
can get away with downloading only the first DVD, or the first couple
of CDs. There are binary-all packages within the early dependencies,
so if we split the binary-all packages out to a common disc, then the
chances are that more people would need to download more of the
images. It would also cause more confusion in terms of downloads - we
already have a lot of people asking for help to find out which images
they need.
>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, basically. In the last 18 months almost all the packages in
Debian have been updated. If you look at source packages, you might
find much more overlap due to the way source packages are split into
upstream tarballs and Debian diffs.
>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?
No, not really. Even in the cases where upstream source has remained
the same, library and compiler changes (for example) mean that the
vast majority of files will have changed.
>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?
At the jigdo level, it would mean trying to keep packages the same as
much as possible. That's not really going to fit alongside development.
>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?
>
>If you think this a garbage idea feel free to say so.
>
>I don't mind.
It's a nice idea and thanks for thinking about things, but
unfortunately I don't think it's going to fly... :-)
--
Steve McIntyre, Cambridge, UK. steve@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Reply to: