Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?
Marius Mauch a écrit : So, do you think it should be enabled by default? Does portage have a way to report which libraries it is keeping around because of preserve-libs ? If there's an easy way to figure that out, then enabling it by default is a very sane and sound idea. Cheers, Rémi -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?
On 29-05-2008 08:54:48 +0200, Rémi Cardona wrote: Marius Mauch a écrit : So, do you think it should be enabled by default? Does portage have a way to report which libraries it is keeping around because of preserve-libs ? If there's an easy way to figure that out, then enabling it by default is a very sane and sound idea. It does so after every merge IIRC, and you can also find them in a file somewhere. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: | The purpose of this is to keep the system operational after library | upgrades until all affected packages could be rebuilt and to simplify | the process, not to avoid the rebuilds. I couldn't find it mentioned in your email, but if portage is effectively doing reference counts, what happens when its reference count gets to 0? Once no ebuilds rely on the old library is it removed automatically, or do the you need to rebuild these message just go away? Is there a way to have portage delete the libraries once it's sure they're no longer necessary? If so, is that done by rebuilding the owning package itself, or by editing the owning pacakge's contents and removing the old library? Does @preserved-rebuild contain just the affected packages, or the package containing the old library as well? (i.e. Does an emerge @preserved-rebuild ensure that the old library will no longer exist on your system, or not?) Basically, if I can safely replace revdep-rebuild with emerge @preserved-rebuild then I'd be happy to keep it enabled. If it's going to leave cruft on the system (or then require manual rebuilds of packages containing preserved libraries to clear out the cruft) then I'd personally be inclined to turn it off and stick with revdep-rebuild... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkg+aSAACgkQu7rWomwgFXoR2ACeJnf+J/pd/GEEh5Ds/Q80sjOR vIkAoKEyLD2lTGfehoSoYLP6pH/R++2J =0sv1 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
Marius Mauch [EMAIL PROTECTED] writes: Also it is not going to be a perfect solution against all runtime link errors, but if enabled it should eliminate the need for revdep-rebuild in most cases. I'm afraid that it will turn, for complex libraries like libexpat and users not using --as-needed, the message telling you the program cannot be started with subtle crashes for symbol collision. preserve-libs would be quite perfect if all libraries out there used versioned symbol, but this is far from true (and some systems Gentoo runs on don't even consider versioned symbol to begin with). Example at hand? When the libexpat transition started, the choice of keeling .so.0 around with .so.1 was discarded right away because: - library libfoo links to libexpat; - program bar links to libfoo; - user is not using --as-needed, so bar has a NEEDED against both libfoo and libexpat; - user rebuilds libfoo, but not bar; or bar and not libfoo, the result is the same; - KABOOM! symbol collision and bar crashes. As much as we want preserve-libs to be an all-curing magic, it's not. When you need to replace a library you need to do so _for all its users at once_, if you allow it to be gradually you're opening the hellgate of symbol collision. My solution would be to disallow _building_ anything that is or depends directly or indirectly on a package on the set until it is removed, or at the request of merging mickeymouse, depending on bar, re-emerging libfoo first, and bar if the user is not using --as-needed (checking the NEEDED lines). With all due respect to everybody, the right course of action here has to be selected by people who knows how the runtime linker works, symbol collision and all the rest, as that's what's at stake here. -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpR6kEe6MGbq.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?
2008-05-29 08:54:48 Rémi Cardona napisał(a): Does portage have a way to report which libraries it is keeping around because of preserve-libs ? portageq list_preserved_libs / -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?
On Thu, 29 May 2008 09:28:16 +0100 Mike Auty [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: | The purpose of this is to keep the system operational after library | upgrades until all affected packages could be rebuilt and to | simplify the process, not to avoid the rebuilds. I couldn't find it mentioned in your email, but if portage is effectively doing reference counts, what happens when its reference count gets to 0? Once no ebuilds rely on the old library is it removed automatically, or do the you need to rebuild these message just go away? They are removed automatically. Marius -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Recent changes wrt python.eclass
Hi people,
All python_mod_* functions are now ROOT aware. I've also modified them
to die if they aren't run in expected phases. Also I plan to make byte
compiling functions print a warning when *.py{c,o} are installed under
/usr/share which is a FHS violation.
The tree and python developer's guide are updated to reflect the
changes.
As a last thing, I want to give some usage notes here so it's
clear for everyone.
* If your package uses distutils.eclass, generally you have nothing to
worry about. By default it'll byte compile python modules under
/usr/$(get_libdir)/python${PYVER}/site-packages/${PN}. If your package
installs a directory with a name other than ${PN} set PYTHON_MODNAME
to the name of directory.
* python_version should only be called if you need any of PYVER*
variables. If your package only uses python.eclass - and not
distutils.eclass, you need to call it when you want to use $python
too. ( Note: Right now python_version is buggy wrt ROOT. This is the
next thing I'm going to fix.)
* Don't call python_mod_cleanup with PYVER like:
Wrong:
python_mod_cleanup \
/usr/$(get_libdir)/python${PYVER}/site-packages/$PN
This is wrong because the python version may change in the meantime.
Instead use:
python_mod_cleanup \
/usr/$(get_libdir)/python*/site-packages/$PN
python_mod_cleanup has a safe default so you can usually avoid passing
any arguments.
These are important stuff I can remember by the time I'm writing this
mail. Python devguide will be updated with these useful information
soon.
So if anything is not clear and/or you have any questions feel free to
bug/poke/stab me :-)
--
Regards,
Ali Polatel
pgpbLsWF5ExNi.pgp
Description: PGP signature
[gentoo-dev] Re: Re: [RFC] Eclass for gnome-python* split
Ali Polatel yazmış:
Mart Raudsepp yazmış:
On L, 2008-05-24 at 10:18 +0300, Ali Polatel wrote:
Arun Raghavan yazmış:
Greetings All,
Hey there
I've been working on an ancient bug [1] requesting a split of the
gnome-python, gnome-python-extras, and gnome-python-desktop ebuilds.
Good for you :P
*snip*
Feedback and comments (and even brickbats ;)) on the eclass are invited.
Attached is a patch for two minor issues with the eclass. First try to
remove py-compile only if it exists. Second, python_mod_optimize is
ROOT aware (since recently).
Does that mean that every python_mod_optimize user (ebuild) that used it
as was expected from python_mod_optimize is now broken for ROOT != /
by installing them into ${ROOT}/${ROOT}/ ?
*fail*
Appearently python_mod_optimize is not ROOT aware (yet). I thought this
patch¹ was committed and didn't bother to check the eclass (silly me).
I'll commit it tomorrow and make sure the tree is consistent.
Join the fun if you have time :-)
¹: http://dev.gentoo.org/~hawking/tmp/python-root_awareness.diff
Done. :-)
--
Regards,
Ali Polatel
pgplmE8XYISCh.pgp
Description: PGP signature
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On Thu, 29 May 2008 11:02:55 +0200 [EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote: Marius Mauch [EMAIL PROTECTED] writes: As much as we want preserve-libs to be an all-curing magic, it's not. When you need to replace a library you need to do so _for all its users at once_, if you allow it to be gradually you're opening the hellgate of symbol collision. That's what `emerge @preserved-rebuild` does, or do you mean something different? My solution would be to disallow _building_ anything that is or depends directly or indirectly on a package on the set until it is removed, or at the request of merging mickeymouse, depending on bar, re-emerging libfoo first, and bar if the user is not using --as-needed (checking the NEEDED lines). Well, with preserve-libs the situation is this (using your example): - user upgrades expat, portage keeps libexpat.so.0 around (some packages might now be linked against both versions if the session included other packages as well) - emerge tells the user to rebuild all affected packages (affected = contains libexpat.so.0 in NEEDED, so includes both libfoo and bar) by using `emerge @preserved-rebuild` (in the future this could also be done automatically, but that won't be before 2.2 final) - when all affected packages have been rebuilt (so their NEEDED entries don't contain libexpat.so.0 anymore) libexpat.so.0 is automatically removed So, if I understand you correctly (probably not), you want portage to prevent the user from building any packages depending on any affected package before the last step is completed? With all due respect to everybody, the right course of action here has to be selected by people who knows how the runtime linker works, symbol collision and all the rest, as that's what's at stake here. Whoever that is is welcome to voice his opinion here, that's the point of this thread after all. Marius -- gentoo-dev@lists.gentoo.org mailing list
