Re: Avoiding the automated ooops effect

jesse <[email protected]> 14 Jul 2003 04:13:30 -0700
Newsgroups gmane.linux.zynot.devel
Message-ID <[email protected]>
--===============2134012068796225==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-c64EgoccE4YBR8xRb9l7"


--=-c64EgoccE4YBR8xRb9l7
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2003-07-13 at 18:22, Klaus-J. Wolf wrote:
> Hi,
>=20
> I guess it's the time for all those proposals which have been ignored at=20
> Gentoo...?
>=20
> I have read the email of Kevin Horn ("Package Priority") and that reminde=
d me=20
> of some old ideas of mine... (though they don't have much in common with =
his=20
> ideas, their objective appears to be comparable).
>=20
> Main wish: Be able to invoke automated update on a regular basis without =
the=20
> risk of a big oops.
>=20
> Solution: 1. Make some installed ebuilds "protected" manually. E.g. glibc=
 can=20
> only be updated if the user knows exactly what he is doing.
>=20
I would love to have the power to "freeze" a package at a version. I.E.
never upgrade it and its dependancy tree ( i.e. mysql/apache etc ) so
that i can emerge -U world  without a care that my main services aren't
going to get borked because some lib or other has versioned.. *( another
solution would to have a real dependancy tree that could then rebuild
anything that is dependant on a package.)Freezing a package would be
nice. =20

> 2. Make some scale on which base a user or a user's algorithm can decide =
if it=20
> prefers a particular ebuild or it doesn't. (Improving the primitive=20
> ACCEPT_KEYWORDS system...) There should be at least one scale like=20
> BROKEN...EXPERIMENTAL...SOLID, classifying the quality of an ebuild. Ofte=
n,=20
> the original author and the ebuild author may dissent, so there should be=
=20
> scale: 1) evaluation by the original author, 2) evaluation by the ebuild'=
s=20
> author, if necessary, split into several platforms/architectures.
>=20
I think in alot or respects this is being addressed by the multiple
trees and tree fall-through  modeles that are being developed.=20


--=-c64EgoccE4YBR8xRb9l7
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/EpBa4rKvBkfUvb0RAofhAJ9s95Vd/rjQSzPTEd11p5SFGiqQOQCgl0i3
1FJrY5Io4VjAiU6sax37LDw=
=nyca
-----END PGP SIGNATURE-----

--=-c64EgoccE4YBR8xRb9l7--


--===============2134012068796225==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Zynot-dev mailing list
[email protected]
http://lists.zynot.org/mailman/listinfo/zynot-dev

--===============2134012068796225==--