Re: Et voila! (was: Re: Slink not installable from CDs)
On 21-Oct-1998, Michael Stone <mstone@itri.loyola.edu> wrote:
> Quoting Tyson Dowd (trd@cs.mu.OZ.AU):
> > You can have it both ways.
> >
> > You can even have all packages files on the first CD as well
> > as duplicates on each CD.
> >
> > With the proposed contents description file I
> > have posted to the list a few times now, you can even have
> > a packages file on every 3rd disk, or every 10th disk,
> > or multiple ones for each CD.
>
> So instead of the directions saying "insert all the disks", they say
> "insert disks A, C, and D." I'm not sure things have been simplified.
The scheme allows flexibility. Simplicity is up to the CD
producer to design. Any scheme that tries to build simplicity
in by making arbitrary rules will be inflexible.
Perhaps sometimes insert A C and D is useful. Perhaps not. Who
cares? You don't need to make the decision now, you can make
it when you make the CDs.
> If you're going to have a seperate package file for non-free and for
> vendor add-ons, which require a seperate read routine, why jump
> through hoops to keep them from having to handle the contrib disk
> seperately?
You do not need a separate read routine, you just need to know
where to find the packages file on the CD set.
>
> And it still doesn't address the problem of someone who burns 2000
> copies each of disks 1, 2, and 3, then finds a critical bug in a package
> on 3. Does he reburn disk 1 also, so he can update the package list?
> Seems like a waste. As I've pointed out, SGI uses the disk-shuffling
> routine, and I don't think that it's a real big problem from the user's
> perspective.
One more time:
It does address this.
One packages file per cd is subsumed by this method.
All packages on the first cd is also subsumed by this method.
So is any other combination.
So if you think that you might have a problem like this, you put the
packages files on each CD. Voila -- you have the SGI-style technique.
Any if someone decides that they are ready to press 1000000 CDs, and
they have checked for errors, they can put all the packages files on the
first CD and save the user inserting multiple CDs.
And if they do make a mistake, they can simply issue an update CD, the
user can insert it when they get it, and it can fix the problems.
They can even put a packages file on the re-issue of the 3rd CD
and instruct customers to insert that CD and get the new packages
file read from it. The newer version of the updated package will ensure
that it is selected instead of the older buggy version.
Because you know which packages are on which CD, you can even tell
the customer to tell the package manager that you no longer have the
old 3rd CD, and it can remove those packages from its database, then
re-populate it with the new CD. Or the 3rd CD could simply contain
the packages files for all the CDs in the re-issue.
The point is you have the flexibility to do things both ways.
You can even have redundant copies of the Packages files just in
case someone loses the first CD, but still wants to use the others.
--
Those who would give up essential liberty to purchase a little temporary
safety deserve neither liberty nor safety. - Benjamin Franklin
Tyson Dowd <tyson@tyse.net> http://tyse.net
Reply to: