Re: Slink to potato upgrade
Well, a problem still is: what about programs users compile for
themselves? I'm also not sure what this buys us, since we are already
recompiling the packages in potato as necessary. Many of our users
simply cannot recompile packages for themselves like that. I, for
one, have Debian on an old machine with an 80 MB hard disk using it as
a router. If I tried to recompile the dist on that box, the network
would have trouble because the drive would fill up.
Also I'm not sure what you mean that they will already have the
correct libraries?
Steve Przepiora <gearhead@twcny.rr.com> writes:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> I have an idea, at first it may sound extreme, but then it will solve alot of
> problems. A little background first, a long time ago I was checking out
> FreeBSD, I was allready a linux user, but I wanted to see what the big todo was
> about it, so I went to one of the web pages and discovered something that
> suprised me, you could recompile _EVERYTHING_ in the dist in one fell swoop.
> What if we set up make files for all required, base and anything essential like
> that, this way upgrading anything required will allready have the correct
> libraries met upone install, those that are needed to upgrade could be static
> bins, and therefore not require anything to be run. The install could be setup
> for a two step proccess, install base/required first, then upgrade anyother
> package. IMHO this would stop any problems with unmet library dependancies.
>
> Steve Przepiora
>
> On Sat, 20 Mar 1999, Wichert Akkerman wrote:
> > >%_
> > Of course potato isn't going to be released anytime soon, but I think we
> > need to think about this really early in order to get this right.
> >
> > Here is the issue: how are we going to make the glibc2 to glibc2.1
> > upgrade as painless as possible? With the bo -> hamm upgrade the
> > approach was reasonably simple: first move the a.out libraries out of
> > the way and then install the new things. But that does not work for this
> > upgrade.
> >
> > Right now the only answer I see is that anything that breaks should
> > simply be ugpraded. But that is not a good solution: we really can't
> > expect users to test all packages to see if they still work and upgrade
> > those that don't. This means we need another approach to this.
> >
> > So, does anyone have some ideas about this?
> >
> > Wichert.
> >
> > --
> > ==============================================================================
> > This combination of bytes forms a message written to you by Wichert Akkerman.
> > E-Mail: wakkerma@cs.leidenuniv.nl
> > WWW: http://www.wi.leidenuniv.nl/~wichert/
> >
>
> - ----------------------------------------
> Content-Type: application/pgp-signature; name="unnamed"
> Content-Transfer-Encoding: 7bit
> Content-Description:
> - ----------------------------------------
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3a
> Charset: noconv
>
> iQCVAwUBNvRlMumHzGy9kqTJAQEqyAP/XVaEo4fYkckkm1GBsxWHw0dnHxPHcQYC
> xl+4jEIVY78HAMKzyGToYT2w1s/qvj58vYPs5zdBQ2a5rDQYN7bmYJWZ+5a2R0j+
> tQJn7XA/RkMLgoUo6bu2O7AssbLNMm0Q7hXTewbFrvWYIR5h0wWEyLNajNRRJET/
> ie0zMFracYU=
> =+TWF
> -----END PGP SIGNATURE-----
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: