[gentoo-dev] RFC: persistence of eclasses for installed packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, As many of you probably know already, bug 46223 [1] prevents the proper uninstallation of a package when one or more of the eclasses that it inherits are missing from the live portage tree. There are essentially two ways to solve this problem: Approach #1: Reuse the saved environment which contains a mixture of eclasses and parts of the package manager (such as portage's ebuild.sh) that performed the installation. Approach #2: Save copies of the raw eclasses and use them, together with the saved ebuild, to recreate the environment. A major advantage of approach #1 is that it can potentially provide complete restoration of the install-time environment. The major disadvantage is that the saved environment needs to be purified so that parts of the package manager that did the install do not interfere with the package manager that does the uninstall. The purification process could potentially be complex or error prone, making it difficult to maintain or unreliable. Simplicity is the major advantage approach #2. The eclasses that are used by a package could be stored in eclasses.tbz2 (much like enviroment.bz2 is currently stored for each installed package), and the environment could be recreated from scratch by using the ebuild and eclasses in the normal inherit process. This wouldn't necessarily allow access to the complete build-time or install-time environment, but that feature is not currently available anyway. If we save the raw eclasses for each installed package, we can easily gain the ability to remove eclasses from the portage tree and make incompatible api changes when necessary, without the complexity of environment purification. What do people think about these two approaches? Personally, I would prefer approach #2 for the sake of simplicity and maintainability. The sooner that we start storing eclasses.tbz2 for each installed package, the sooner that we will be able to have more freedom with the eclasses in the live portage tree. Zac [1] http://bugs.gentoo.org/show_bug.cgi?id=46223 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFTF58/ejvha5XGaMRApOeAJ9CncD89mRUy/mhyVZnhFjmazjYYACfYhdy 4qLqBySCLvAyuNm58bqXZnY= =Ailg -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: persistence of eclasses for installed packages
Zac Medico kirjoitti: What do people think about these two approaches? Personally, I would prefer approach #2 for the sake of simplicity and maintainability. The sooner that we start storing eclasses.tbz2 for each installed package, the sooner that we will be able to have more freedom with the eclasses in the live portage tree. One thing that comes to mind is that how do we handle the case where the old version of the eclass has a major bug in pkg_postrm for example. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: persistence of eclasses for installed packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: Zac Medico kirjoitti: What do people think about these two approaches? Personally, I would prefer approach #2 for the sake of simplicity and maintainability. The sooner that we start storing eclasses.tbz2 for each installed package, the sooner that we will be able to have more freedom with the eclasses in the live portage tree. One thing that comes to mind is that how do we handle the case where the old version of the eclass has a major bug in pkg_postrm for example. I suppose we could check the live tree for the required eclasses and use them if they are all available. Perhaps, in that case, we should use the live ebuild too if it is available. In cases where something isn't available in the live tree we could fall back to the saved files as a last resort. We'd have to maintain api compatibility, but at least there would still be a reasonable chance for the user to do a normal uninstall after some eclasses have been removed. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFTIK3/ejvha5XGaMRAiRTAKCV31alUOZjVaC5qh3iWNBlEuW/wwCdFxiz TgJ4hqxMap9thhy1VIEQrOk= =o5pR -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: persistence of eclasses for installed packages
Zac Medico ha scritto: Petteri Räty wrote: Zac Medico kirjoitti: What do people think about these two approaches? Personally, I would prefer approach #2 for the sake of simplicity and maintainability. The sooner that we start storing eclasses.tbz2 for each installed package, the sooner that we will be able to have more freedom with the eclasses in the live portage tree. One thing that comes to mind is that how do we handle the case where the old version of the eclass has a major bug in pkg_postrm for example. I suppose we could check the live tree for the required eclasses and use them if they are all available. Perhaps, in that case, we should use the live ebuild too if it is available. In cases where something isn't available in the live tree we could fall back to the saved files as a last resort. We'd have to maintain api compatibility, but at least there would still be a reasonable chance for the user to do a normal uninstall after some eclasses have been removed. Zac could it be the other way around ? Use the saved and if it fail try to use the current? Reason for this is that otherwise you need to maintain in the tree code to un-merge very old packages, needlessy bloating the current, plus experience teach this is very error prone. There is a problem however with this approach, you can't fix bug where the (original ebuild) exit code is success but the behaviour is damn bugged. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: persistence of eclasses for installed packages
On Sat, 04 Nov 2006 13:02:19 + Francesco Riosa [EMAIL PROTECTED] wrote: There is a problem however with this approach, you can't fix bug where the (original ebuild) exit code is success but the behaviour is damn bugged. You can, but perhaps not in a nice, automatic, or particularly elegant way. Just send out a (glep42) news item saying The stored version of foo.eclass has a serious bug. Please remove it from your installed package database and re-install any packages which used it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: persistence of eclasses for installed packages
On Sat, 4 Nov 2006 06:46:02 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Saturday 04 November 2006 06:14, Petteri Räty wrote: Zac Medico kirjoitti: What do people think about these two approaches? Personally, I would prefer approach #2 for the sake of simplicity and maintainability. The sooner that we start storing eclasses.tbz2 for each installed package, the sooner that we will be able to have more freedom with the eclasses in the live portage tree. One thing that comes to mind is that how do we handle the case where the old version of the eclass has a major bug in pkg_postrm for example. I think it is also possible that changes into a eclass introduce a new unexpected bug, so this shouldn't be the only reason to stop doing this. How about introducing a variable OBSOLETES=list of cvs revisions, this way it can be automatically detected if the cached ebuild/eclass can be used or if it needs to be ignored and the newer version from portage that obsoletes it has to be used? that would be the only thing keeping me from saying LETS DO #2 NOW ;) I'd vote, lets do #2 in any case. Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: persistence of eclasses for installed packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Francesco Riosa wrote: could it be the other way around ? Use the saved and if it fail try to use the current? Reason for this is that otherwise you need to maintain in the tree code to un-merge very old packages, needlessy bloating the current, plus experience teach this is very error prone. There is a problem however with this approach, you can't fix bug where the (original ebuild) exit code is success but the behaviour is damn bugged. It gets a little messy if we have to check exit codes like that. If pkg_prerm() fails with the saved ebuild/eclasses, then we substitute everything that we can from the live tree and then try again? What about if pkg_prerm() succeeds with the saved ebuild/eclasses, but then pkg_postrm() fails? I suppose we would substitute everything that we can from the live tree at that point. It's a little messy but I guess we can do that if that's how people think it should behave. Anyway, portage-2.1.2 is nearing a final release and it may be the stable version of portage for 2007.0, so it might be a good idea to make it start saving eclasses.tbz2 for installed packages now (even if it doesn't actually use them for anything). I imagine that it will just be a bzipped tarball containing an eclass directory with all of the inherited eclasses inside. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFTTa9/ejvha5XGaMRAmI+AJ0URJ9FEssxQsT/qEvnRqJkUppQBACg1Isa 76JGdGN7DzmFBwBndd6DujA= =dsoy -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: persistence of eclasses for installed packages
On Sat, Nov 04, 2006 at 04:56:31PM -0800, Zac Medico wrote: Francesco Riosa wrote: could it be the other way around ? Use the saved and if it fail try to use the current? Reason for this is that otherwise you need to maintain in the tree code to un-merge very old packages, needlessy bloating the current, plus experience teach this is very error prone. There is a problem however with this approach, you can't fix bug where the (original ebuild) exit code is success but the behaviour is damn bugged. It gets a little messy if we have to check exit codes like that. Can't rely on exit codes coming back from phases anyways; ebuild/eclass devs don't force it to be 0 for success- last time I tried checking exit code, just wound up making things bail out a lot due to false positives. If pkg_prerm() fails with the saved ebuild/eclasses, then we substitute everything that we can from the live tree and then try again? What about if pkg_prerm() succeeds with the saved ebuild/eclasses, but then pkg_postrm() fails? I suppose we would substitute everything that we can from the live tree at that point. It's a little messy but I guess we can do that if that's how people think it should behave. This approach should *never* be tried; reasons- You're going to have fork for every search attempt to protect the original env. from getting crap from failing eclasses Even if you find a combination that doesn't explode, there is no gurantee it'll actually run completely; whats nasty is if it *partially* runs; (pre|pkg)(inst|rm) are not tracked in any fashion, so any changes they do t the livefs isn't tracked. Further, ebuilds/eclasses *do* pair prerm and postrm changes; swapping in a different phase func their requires ebuild/eclass devs to always rely on the same state vars between those phases (not going to happen). This situation gets massively worse when (yes when) dyanmic eclasses (able to be removed, api can change) hits, since at least with the current static eclasses folks are forced to keep things compatible. Remove that restriction, and this proposed approach becomes a much worse minefield- end result there is that dynamic eclasses cannot be implemented until whats proposed above is backed out. Anyway, portage-2.1.2 is nearing a final release and it may be the stable version of portage for 2007.0, so it might be a good idea to make it start saving eclasses.tbz2 for installed packages now (even if it doesn't actually use them for anything). I imagine that it will just be a bzipped tarball containing an eclass directory with all of the inherited eclasses inside. Env handling isn't something that should be rushed (this includes slipping in eclasses.tbz2, which I posit will not be used); the data needed has been there for a *long* time already, use it. ~harring pgp7vmoqx5YIx.pgp Description: PGP signature
