Re: [gentoo-dev] emerge -C eselect-python disaster
On Sun, 24 Jan 2010, Benny Pedersen wrote: it removes python-wrapper and this remove python link from /usr/bin/python linked to /usr/bin/python-wrapper so all portage does not work after this, It's a run-time dependency of python, so what did you expect? my dump question why is it not listed as a system pkg when it really seems so important ? Python itself is not in the system set, so why should the eselect module be? Ulrich
Re: [gentoo-dev] emerge -C eselect-python disaster
On 01/24/2010 07:12 AM, Benny Pedersen wrote: should not be marked as system ? it removes python-wrapper and this remove python link from /usr/bin/python linked to /usr/bin/python-wrapper so all portage does not work after this, but i solved it with a quickpkg from another host my dump question why is it not listed as a system pkg when it really seems so important ? Removing packages with emerge -C is always potentially dangerous. The recommended tool these days is emerge --depclean. emerge -C really only comes to use with blockers and then maintainers should design the upgrade paths so that you don't need to remove anything that breaks things. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] emerge -C eselect-python disaster
On 01/24/2010 07:12 AM, Benny Pedersen wrote: should not be marked as system ? it removes python-wrapper and this remove python link from /usr/bin/python linked to /usr/bin/python-wrapper so all portage does not work after this, but i solved it with a quickpkg from another host my dump question why is it not listed as a system pkg when it really seems so important ? The meaning of the system set is to have only the packages directly required to have a minimal functioning system. Having python by itself is not a requirement for that but having package management is. As a consequence python gets pulled in by portage. We could have a separate list for packages for which the PM should tell the user that he's an idiot of course but the best thing is to educate users that emerge -C is dangerous. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] emerge -C eselect-python disaster
On 1/24/10, Benny Pedersen m...@junc.org wrote: should not be marked as system ? it removes python-wrapper and this remove python link from /usr/bin/python linked to /usr/bin/python-wrapper so all portage does not work after this, but i solved it with a quickpkg from another host my dump question why is it not listed as a system pkg when it really seems so important ? Nearly identical question was mulled over in a discussion last spring over at gentoo-user list. Scan for ARGH I uninstalled python in the archives if you are interested. IIRC there was a suggestion to make the system set dynamically grow to contain all of the required dependencies of the packages explicitly listed in the system set, but I'm not sure if it went anywhere. Anyways, the current contents of @system cause all kinds of surprises, for example to FEATURES=buildsyspkg users who rely on the feature without realizing how small (and even incomplete) @system actually is. -- Arttu V.
Re: [gentoo-dev] emerge -C eselect-python disaster
2010/1/24 Petteri Räty betelge...@gentoo.org: The meaning of the system set is to have only the packages directly required to have a minimal functioning system. Having python by itself is not a requirement for that but having package management is. You can't have functioning package management without the hard dependencies it requires. So both portage and python should be in the system set. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] emerge -C eselect-python disaster
Arttu V. wrote: On 1/24/10, Benny Pedersen m...@junc.org wrote: should not be marked as system ? it removes python-wrapper and this remove python link from /usr/bin/python linked to /usr/bin/python-wrapper so all portage does not work after this, but i solved it with a quickpkg from another host my dump question why is it not listed as a system pkg when it really seems so important ? Nearly identical question was mulled over in a discussion last spring over at gentoo-user list. Scan for ARGH I uninstalled python in the archives if you are interested. IIRC there was a suggestion to make the system set dynamically grow to contain all of the required dependencies of the packages explicitly listed in the system set, but I'm not sure if it went anywhere. Anyways, the current contents of @system cause all kinds of surprises, for example to FEATURES=buildsyspkg users who rely on the feature without realizing how small (and even incomplete) @system actually is. I just picked a random reply here. My $0.02 worth. If I try to remove portage itself, I get this: r...@smoker / # emerge -Ca portage These are the packages that would be unmerged: * Not unmerging package sys-apps/portage-2.2_rc61 since there is no valid * reason for portage to unmerge itself. No packages selected for removal by unmerge r...@smoker / # It appears you can't even remove portage at all. Now call me silly, couldn't it be said that removing something that would prevent the package manager from working constitute a little warning? After all, most likely the person is not thinking clearly that day and most likely doesn't REALLY want to do this. Is there not a way to at the very least post a warning and then ask a 'are you sure' question like it does with the -a option? It's just that as a newbie ages ago, I did this too. I didn't realize that it was a nasty boo boo until afterwards. dale crawls back under his rock Dale :-) :-)
[gentoo-dev] Last rites: dev-ruby/activerecord-jdbc
# Hans de Graaff gra...@gentoo.org (23 Jan 2010) # Installs only for ruby 1.8 but it actually a JRuby package # that installs .jar files. Deprecated. # Last rited: to be removed in 30 days. dev-ruby/activerecord-jdbc In its current state is does not install a working set of files. JRuby support is currently being updated. As part of that effort a replacement for activerecord-jdbc may be added. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
Le dimanche 17 janvier 2010 à 13:37 +0100, Ben de Groot a écrit : 2010/1/17 Paweł Hajdan, Jr. phajdan...@gentoo.org: I wonder why the affected package (eselect-opengl) couldn't run lafilefixer itself. It's mandatory for all users, and would save a lot of frustration. Indeed. You can simply have this version of eselect-opengl depend on lafilefixer and run it in pkg_postinst. Cheers, Please do not lafilefixer without restricting the scope of the changes it does to libGL.la specifically. It changes md5sum of installed files (which then does not match what is recorded by portage at install), it will also potentially hide bugs from packages dropping la files without a word (and this is bad pratice/communication too which should get reported). -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
[gentoo-dev] built_with_use removal
I looked at what kind of a difference cvs up made to built_with_use usage. betelge...@pena /usr/portage $ grep --include *.ebuild built_with_use -r . | wc -l 690 cvs up betelge...@pena /usr/portage $ grep --include *.ebuild built_with_use -r . | wc -l 708 There should be no legitimate reason for the number to go up so please whenever bumping ebuilds, remove the usage of built_with_use. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] emerge -C eselect-python disaster
On 01/24/2010 03:02 PM, Ben de Groot wrote: 2010/1/24 Petteri Räty betelge...@gentoo.org: The meaning of the system set is to have only the packages directly required to have a minimal functioning system. Having python by itself is not a requirement for that but having package management is. You can't have functioning package management without the hard dependencies it requires. So both portage and python should be in the system set. Cheers, Why should we keep redundant information in the list? Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-misc/vnc
# Raúl Porcel armi...@gentoo.org (24 Jan 2010) # Upstream stopped developing open source version, # heavy patching done by Fedora # and they've deprecated it for some time ago. # net-misc/tigervnc is its replacement # To be removed in 30 days net-misc/vnc
Re: [gentoo-dev] built_with_use removal
On 1/24/10 5:51 PM, Petteri Räty wrote: There should be no legitimate reason for the number to go up so please whenever bumping ebuilds, remove the usage of built_with_use. How about adding a repoman check for that? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] emerge -C eselect-python disaster
2010/1/24 Petteri Räty betelge...@gentoo.org: On 01/24/2010 03:02 PM, Ben de Groot wrote: You can't have functioning package management without the hard dependencies it requires. So both portage and python should be in the system set. Why should we keep redundant information in the list? How is that redundant? Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
[gentoo-dev] Re: [gentoo-dev-announce] built_with_use removal
Il giorno dom, 24/01/2010 alle 18.51 +0200, Petteri Räty ha scritto:
There should be no legitimate reason for the number to go up so please
whenever bumping ebuilds, remove the usage of built_with_use.
There is still legitimate use when you're not using it for dependencies.
See for instance PulseAudio ebuild:
local pkg=media-plugins/alsa-plugins
if has_version ${pkg} ! built_with_use --missing false ${pkg}
pulseaudio; then
elog
elog You have alsa support enabled so you probably want to
install
elog ${pkg} with pulseaudio support to have
elog alsa using applications route their sound through
pulseaudio
fi
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
Re: [gentoo-dev] built_with_use removal
On 01/24/2010 08:09 PM, Paweł Hajdan, Jr. wrote: On 1/24/10 5:51 PM, Petteri Räty wrote: There should be no legitimate reason for the number to go up so please whenever bumping ebuilds, remove the usage of built_with_use. How about adding a repoman check for that? Paweł Already done today :) Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] emerge -C eselect-python disaster
On 01/24/2010 08:20 PM, Ben de Groot wrote: 2010/1/24 Petteri Räty betelge...@gentoo.org: On 01/24/2010 03:02 PM, Ben de Groot wrote: You can't have functioning package management without the hard dependencies it requires. So both portage and python should be in the system set. Why should we keep redundant information in the list? How is that redundant? Cheers, The problem the original poster wanted to solve is having a warning when trying to unmerge something in system. The best way here is to file a Portage enhancement request and not pollute the profile system set marking. The purpose of the packages file is to describe what needs to be installed for a minimal system to work so it doesn't make sense to pollute it with implementation details. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] emerge -C eselect-python disaster
On Sunday 24 January 2010 00:12:39 Benny Pedersen wrote: it removes python-wrapper and this remove python link from /usr/bin/python linked to /usr/bin/python-wrapper so all portage does not work after this, but i solved it with a quickpkg from another host sounds a bug that should be filed so it can be fixed -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-dev-announce] built_with_use removal
On 01/24/2010 10:12 PM, Diego Elio “Flameeyes” Pettenò wrote:
Il giorno dom, 24/01/2010 alle 18.51 +0200, Petteri Räty ha scritto:
There should be no legitimate reason for the number to go up so please
whenever bumping ebuilds, remove the usage of built_with_use.
There is still legitimate use when you're not using it for dependencies.
See for instance PulseAudio ebuild:
local pkg=media-plugins/alsa-plugins
if has_version ${pkg} ! built_with_use --missing false ${pkg}
pulseaudio; then
elog
elog You have alsa support enabled so you probably want to
install
elog ${pkg} with pulseaudio support to have
elog alsa using applications route their sound through
pulseaudio
fi
Use EAPI 2 and has_version ${pkg}[use]
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] emerge -C eselect-python disaster
On 01/24/2010 01:20 PM, Ben de Groot wrote: 2010/1/24 Petteri Rätybetelge...@gentoo.org: On 01/24/2010 03:02 PM, Ben de Groot wrote: Why should we keep redundant information in the list? How is that redundant? Well, I doubt we'll get away from python in the system set anytime soon, but imagine the results of having a policy that anything that is a dependency of something in system needs to be in system. Now the system set is three times larger than it is now. There is also no easy way to tell whether something is in the set simply because it is a dependency. Then in the future if something is no longer a dependency it will be installed on every gentoo system unnecessarily. Sure, we can clean things up every once in a while, and maybe even automate that, but what would be the point. The whole reason we have dependency management in our package managers is so that you don't have to worry about details like what package requires what. Package managers shouldn't make it trivial to accidentally remove a dependency in an unsafe manner Rich
Re: [gentoo-dev] emerge -C eselect-python disaster
Petteri Räty wrote: On 01/24/2010 08:20 PM, Ben de Groot wrote: 2010/1/24 Petteri Räty betelge...@gentoo.org: On 01/24/2010 03:02 PM, Ben de Groot wrote: You can't have functioning package management without the hard dependencies it requires. So both portage and python should be in the system set. Why should we keep redundant information in the list? How is that redundant? Cheers, The problem the original poster wanted to solve is having a warning when trying to unmerge something in system. The best way here is to file a Portage enhancement request and not pollute the profile system set marking. The purpose of the packages file is to describe what needs to be installed for a minimal system to work so it doesn't make sense to pollute it with implementation details. Regards, Petteri Since unmerging python results in a broken system, I'm not sure how this pollutes anything. The system set is to maintain a working and bootable system that can install packages and portage requires python to work. What good is a Gentoo system without a working package manager? Is there something that I am missing here? For me, system should include the things needed for booting and for the package manager to work. If it can't contain python then portage has a problem. As I pointed out in another reply, portage won't let you unmerge itself but it will let you unmerge a package that will render portage useless. If I can unmerge python then portage should just go ahead and let me unmerge portage itself too. At least it is easier to repair removing portage. Dale :-) :-)
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-01-24 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2010-01-24 23h59 UTC. Removals: app-doc/howto-html 2010-01-19 00:29:33 dirtyepic app-doc/howto-html-single 2010-01-19 00:29:33 dirtyepic app-doc/howto-pdf 2010-01-19 00:29:34 dirtyepic app-doc/howto-ps2010-01-19 00:29:34 dirtyepic app-doc/howto-text 2010-01-19 00:29:35 dirtyepic games-strategy/freelords2010-01-20 18:37:13 mr_bones_ app-i18n/ibus-table-easy2010-01-20 23:02:09 matsuu app-i18n/ibus-table-quick 2010-01-20 23:02:09 matsuu app-admin/partgui 2010-01-22 18:41:02 phosphan app-i18n/ibus-table-thai2010-01-23 09:37:55 matsuu app-i18n/ibus-table-viqr2010-01-23 09:37:55 matsuu app-mobilephone/moto4lin2010-01-23 14:23:20 ssuominen dev-util/crossvc2010-01-23 14:24:21 ssuominen dev-util/esvn 2010-01-23 14:24:22 ssuominen dev-util/valkyrie 2010-01-23 14:24:22 ssuominen dev-util/xxdiff 2010-01-23 14:24:23 ssuominen media-gfx/lprof 2010-01-23 14:28:40 ssuominen app-i18n/qimhangul 2010-01-23 14:30:27 ssuominen media-video/qdvdauthor 2010-01-23 14:32:58 ssuominen media-video/qdvdauthor-templates2010-01-23 14:32:58 ssuominen media-sound/cm 2010-01-23 14:46:18 scarabeus sys-apps/inputd 2010-01-23 14:49:27 scarabeus app-forensics/airt 2010-01-23 14:50:50 scarabeus dev-python/gadfly 2010-01-23 14:55:09 scarabeus app-i18n/jless 2010-01-23 14:56:19 scarabeus media-libs/akode2010-01-23 14:57:21 ssuominen x11-misc/bbconf 2010-01-23 14:58:06 ssuominen sys-boot/sysload2010-01-23 14:58:50 scarabeus x11-drivers/xf86-video-via 2010-01-23 14:59:44 scarabeus x11-misc/xplore 2010-01-23 15:02:02 scarabeus net-dns/ldapdns 2010-01-23 15:03:23 scarabeus profiles/default-linux/mips 2010-01-23 16:07:20 ssuominen app-dicts/qvortaro 2010-01-24 18:41:37 ssuominen app-office/qtstalker2010-01-24 18:42:23 ssuominen virtual/poppler-qt3 2010-01-24 18:43:10 ssuominen dev-libs/poppler-qt32010-01-24 18:43:52 ssuominen dev-db/mysqlnavigator 2010-01-24 18:44:31 ssuominen games-emulation/mupen64 2010-01-24 18:47:08 ssuominen games-emulation/mupen64-alsasnd 2010-01-24 18:47:18 ssuominen games-emulation/mupen64-blight-tr64gl 2010-01-24 18:47:21 ssuominen games-emulation/mupen64-blight-uhleaudio2010-01-24 18:47:22 ssuominen games-emulation/mupen64-glide64 2010-01-24 18:47:24 ssuominen games-emulation/mupen64-riceplugin 2010-01-24 18:47:27 ssuominen Additions: app-vim/surround2010-01-19 23:46:53 spatz sci-libs/ccfits 2010-01-20 02:32:36 bicatali sci-biology/bfast 2010-01-21 18:25:31 weaver dev-python/python-daemon2010-01-22 13:10:46 djc app-crypt/sgeps 2010-01-22 18:28:23 flameeyes lxde-base/lxde-icon-theme 2010-01-22 20:17:55 vostorga app-dicts/goldendict2010-01-23 13:04:13 hwoarang dev-db/vbisam 2010-01-23 23:09:54 phosphan games-emulation/nestopia2010-01-24 07:49:21 mr_bones_ media-sound/xmp 2010-01-24 15:25:00 ssuominen dev-ruby/prawn-core 2010-01-24 15:39:47 graaff dev-ruby/prawn-security 2010-01-24 15:43:02 graaff dev-util/coccinelle 2010-01-24 18:07:36 aballier media-libs/opengl-apple 2010-01-24 18:58:57 grobian dev-util/fossil 2010-01-24 20:21:44 vapier dev-libs/libnatspec 2010-01-24 21:05:40 vapier
Re: [gentoo-dev] emerge -C eselect-python disaster
On Sun, Jan 24, 2010 at 19:02, Dale rdalek1...@gmail.com wrote: Since unmerging python results in a broken system, I'm not sure how this pollutes anything. The system set is to maintain a working and bootable system that can install packages and portage requires python to work. What good is a Gentoo system without a working package manager? There are two issues here: * Avoiding hacks for deciding which packages are needed for system * Helping users avoid the dangerous mistake of crippling the package manager. Here's how I see this break down. To avoid crippling the package manager, the user must be warned of an action that will cripple the package manager. If removing python cripples the package manager, then warn the user. It's quite simple. Adding python to the system set is messy, as pointed out, but somehow there must be a way to determine that python is needed by the package manager. The last remaining option (without adding any new features) is to track on which packages are required by the system set and warning about removing any packages required by any package in the system set. This seems like a good solution. I could also argue that using emerge -C period is dangerous, as some here have mentioned. As far as I can tell, the best way to remove a package is to edit the package out of /var/lib/portage/world file and then letting portage safely remove packages via --depclean. (This is outside the current topic, of course, so if anyone wants to seriously propose this it should be re-posted under a new subject heading.) -- Jacob For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened. Are you ready?
Re: [gentoo-dev] emerge -C eselect-python disaster
Jacob Godserv wrote: On Sun, Jan 24, 2010 at 19:02, Dale rdalek1...@gmail.com wrote: Since unmerging python results in a broken system, I'm not sure how this pollutes anything. The system set is to maintain a working and bootable system that can install packages and portage requires python to work. What good is a Gentoo system without a working package manager? There are two issues here: * Avoiding hacks for deciding which packages are needed for system * Helping users avoid the dangerous mistake of crippling the package manager. Here's how I see this break down. To avoid crippling the package manager, the user must be warned of an action that will cripple the package manager. If removing python cripples the package manager, then warn the user. It's quite simple. Adding python to the system set is messy, as pointed out, but somehow there must be a way to determine that python is needed by the package manager. The last remaining option (without adding any new features) is to track on which packages are required by the system set and warning about removing any packages required by any package in the system set. This seems like a good solution. I could also argue that using emerge -C period is dangerous, as some here have mentioned. As far as I can tell, the best way to remove a package is to edit the package out of /var/lib/portage/world file and then letting portage safely remove packages via --depclean. (This is outside the current topic, of course, so if anyone wants to seriously propose this it should be re-posted under a new subject heading.) Well put. I would agree that a simple warning should be given before removing a system package or a package that system must have, especially portage. Maybe what portage needs is a reverse -n feature. Instead of adding something to the world file, it removes a unwanted package from the world file and then the user could use --depclean to remove that package and its no longer needed friends. I assume this is doable. Dale :-) :-)
Re: [gentoo-dev] emerge -C eselect-python disaster
On 01/24/2010 07:02 PM, Dale wrote: Is there something that I am missing here? For me, system should include the things needed for booting and for the package manager to work. It should include the programs directly involved in booting, and the package manager. I'm not sure that it should contain their dependencies - since that information can be derived from the packages themselves. As I pointed out in another reply, portage won't let you unmerge itself but it will let you unmerge a package that will render portage useless. Well, it shouldn't allow you to unmerge anything that will render ANYTHING useless without some explicit instruction to do so. The documentation does warn of this behavior: --unmerge (-C) WARNING: This action can remove important packages! Removes all matching packages. This does no checking of dependencies, so it may remove packages necessary for the proper operation of your system. Its arguments can be atoms or ebuilds. For a dependency aware version of --unmerge, use --depclean or --prune. If you use --depclean to remove your package then you're safe. Note - the command line option names are not well-chosen here. -C should really be --unmerge-without-checking-dependencies-unsafe or some other obnoxious option, and --depclean should be the easy to type parameter.
Re: [gentoo-dev] emerge -C eselect-python disaster
Richard Freeman wrote: On 01/24/2010 07:02 PM, Dale wrote: Is there something that I am missing here? For me, system should include the things needed for booting and for the package manager to work. It should include the programs directly involved in booting, and the package manager. I'm not sure that it should contain their dependencies - since that information can be derived from the packages themselves. I see your point but if removing python renders portage useless, then portage is not any good either. So, if portage will not warn against removing python, it may as well not warn about removing portage either. The system needs both to work. As I pointed out in another reply, portage won't let you unmerge itself but it will let you unmerge a package that will render portage useless. Well, it shouldn't allow you to unmerge anything that will render ANYTHING useless without some explicit instruction to do so. The documentation does warn of this behavior: --unmerge (-C) WARNING: This action can remove important packages! Removes all matching packages. This does no checking of dependencies, so it may remove packages necessary for the proper operation of your system. Its arguments can be atoms or ebuilds. For a dependency aware version of --unmerge, use --depclean or --prune. If you use --depclean to remove your package then you're safe. Note - the command line option names are not well-chosen here. -C should really be --unmerge-without-checking-dependencies-unsafe or some other obnoxious option, and --depclean should be the easy to type parameter. I agree that since --depclean has improved, a LOT, that it is the safest way to remove a package. Maybe that reverse -n feature may be considered. Reserve the -C for someone that knows what not to remove. Dale :-) :-)
