Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
В Чтв, 29/05/2008 в 11:02 +0200, Diego 'Flameeyes' Pettenò пишет: > 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. Is there any reason why --as-needed is not enabled "by default"? -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
В Чтв, 29/05/2008 в 15:42 +, Raul Porcel (armin76) пишет: > armin76 08/05/29 15:42:29 > > Modified: package.mask > Log: > P.mask net-dns/resolvconfig-gentoo as per bug #219270 > > Revision ChangesPath > 1.8663 profiles/package.mask Whenever you modify anything in profiles directory, please, fill in ChangeLog. ChangeLogs became useless if only part of developers fill them. Just to remind. There are per-arch ChangeLog, base profile ChangeLog, features ChangeLog and for other stuff ChangeLog: /usr/portage/profiles/base/ChangeLog /usr/portage/profiles/arch/sh/ChangeLog [snip other archs ChangeLog] /usr/portage/profiles/default-bsd/ChangeLog /usr/portage/profiles/embedded/ChangeLog /usr/portage/profiles/default-linux/arm/ChangeLog [snip other archs ChangeLog] /usr/portage/profiles/hardened/x86/ChangeLog /usr/portage/profiles/features/ChangeLog /usr/portage/profiles/ChangeLog Thus whenever you change anything in arch profile, or in base or features subdirectory use relevant ChangeLog. For other changes like local USE flags documentation, masking/unmasking/updating masks (not comments :)) use /usr/portage/profiles/ChangeLog. Thank you. -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
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
[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
[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
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
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?
2008-05-29 01:13:16 Marius Mauch napisał(a): > One concern raised by some people is that it might cause old libraries > with security issues to stay on the system for eternity even though > the package was upgraded, and eventually be preferred by new builds. This shouldn't be a problem, because unneeded preserved libraries are automatically deleted. > So, do you think it should be enabled by default? Yes. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[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?
-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
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