View previous topic :: View next topic |
Author |
Message |
Klavs Guru


Joined: 22 May 2002 Posts: 536 Location: Denmark
|
Posted: Mon Jun 02, 2003 12:31 pm Post subject: portage suggestion - --exclude option |
|
|
Hi guys,
I was wondering if I was the only one who could really use an --exclude option.
emerge -Uu php (or whatever) often gives me 30-50 packages needing to be upgraded - some of which is big packages (like X) due to a small -rX change.
Therefore it would be great with an --exclude option, so I could list the packages not to be considered. The --exclude-file option would be cool too.
Even cooler would it be to have a --disregard-revision-only-changes flag too or something like that  _________________ Best regards,
Klavs Klavsen
Denmark
Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38. |
|
Back to top |
|
 |
Loke Apprentice

Joined: 25 May 2002 Posts: 274 Location: Norway
|
Posted: Mon Jun 02, 2003 12:53 pm Post subject: |
|
|
Both "problems" you describe are solved (by you) through the USE="" flags in /etc/make.conf and by (gentoo dev's) ensuring ebuilds are properly written and dont request a package upgrade unless its neccesary.
You can also use the emerge --inject to exclude packages you dont want, to trick portage into thinking its already availabe. So everything you requested is already in Gentoo
Edit: Obviously, you didnt ask about the USE="" option, so never mind that BUT: You can still inject packages, like I mentioned above. However, when an ebuild requires one or several package upgrades it _should_ be a reason for doing so (eg. needs it to work properly) However I suspect most never ebuilds just wants the latest version anyway... I know mine does hehe...
What Id like as a feature instead, is a list of DO_NOT_TOUCH_THESE_PROGRAMS_EVER_NEVER so I could put what I want into this list and never have to worry about them being screwed by an emerge world or something similar. I am not aware of any features that does this. |
|
Back to top |
|
 |
Klavs Guru


Joined: 22 May 2002 Posts: 536 Location: Denmark
|
Posted: Mon Jun 02, 2003 1:01 pm Post subject: |
|
|
Nope it's not.
I have X installed - and I want it to be. I just don't want it to be upgraded when I run emerge -Uu php - but I don't want to manually list the 27 other upgrades it suggests when running emerge -Uu (or even with --deep) php because I don't want it to upgrade X.
You see what I mean? _________________ Best regards,
Klavs Klavsen
Denmark
Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38. |
|
Back to top |
|
 |
Loke Apprentice

Joined: 25 May 2002 Posts: 274 Location: Norway
|
Posted: Tue Jun 03, 2003 11:21 am Post subject: |
|
|
Yes, I see what you mean - and ive said how to solve it Just emerge --inject the package you dont want to upgrade, and I recon it will work. |
|
Back to top |
|
 |
Klavs Guru


Joined: 22 May 2002 Posts: 536 Location: Denmark
|
Posted: Tue Jun 03, 2003 11:49 am Post subject: |
|
|
So you want me to inject packages that I don't want upgraded. so if I don't want 10 out of 50 packages upgraded, I should inject them - and then when a new revision comes along - I should inject that again ?
Doesn't sound like a very good solution, to what I think is a fair need, considering how often Gentoo's packages get upgraded. _________________ Best regards,
Klavs Klavsen
Denmark
Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38. |
|
Back to top |
|
 |
plate Bodhisattva


Joined: 25 Jul 2002 Posts: 1663 Location: Berlin
|
Posted: Tue Jun 03, 2003 12:28 pm Post subject: |
|
|
Fair enough. But injecting does provide an immediate workaround, and nobody stops you from using fictitious version numbers. emerge -i x11-base/xfree86-5.0 should leave your installation well outside the greedy reach of portage upgrade attempts for quite a while.  |
|
Back to top |
|
 |
Loke Apprentice

Joined: 25 May 2002 Posts: 274 Location: Norway
|
Posted: Tue Jun 03, 2003 8:55 pm Post subject: |
|
|
Exactly
Edit: I'd still like a DO-NOT-TOUCH-THESE-PROGRAMS-EVER-NEVER list in Gentoo. I think that would solve most of the problems you describe... There are other packages besides X id like emerge to never touch. |
|
Back to top |
|
 |
crazy-bee Apprentice


Joined: 03 Jan 2003 Posts: 170
|
Posted: Sat Jun 07, 2003 9:41 am Post subject: |
|
|
Count me in.
I definitly need such an option, too.
I helped myself with marking the packages I do not want to be touched as masked, but since this is always overwritten with an emerge sync, it sucks since it has to be done manually. |
|
Back to top |
|
 |
Lion Apprentice


Joined: 23 Jun 2002 Posts: 207
|
Posted: Sun Jun 08, 2003 7:32 am Post subject: The problem is that -u does too much! |
|
|
I think that we don't need an --exclude here, but that the --upgrade option does too much. IMO "emerge --upgrade package" should do only that: upgrade the named package if an upgrade is available, and only upgrade dependencies if the dependency upgrade is REQUIRED by the newer package.
Instead, now, if package depends on X, for example, and you --upgrade package, an upgrade for X is automatically performed, even if package would function perfectly with the older version of X.
I don't see any reason why --upgrade should do this.
For automatic update of dependencies, we have --deep, don't we?
I think I'm going to file a request for change of the --update behaviour in bugzilla. |
|
Back to top |
|
 |
Matje l33t

Joined: 29 Oct 2002 Posts: 619 Location: Hasselt, Belgium
|
Posted: Sun Jun 08, 2003 8:24 am Post subject: |
|
|
You might want to try emerge -U, without the -u flag. This way, only the packages necessary get installed, instead of telling portage to upgrade everything php depends of...
Code: | matje@lambik matje $ emerge -up php
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild UD] sys-libs/glibc-2.3.1-r4 [2.3.2-r1]
[ebuild U ] app-crypt/mhash-0.8.18-r1 [0.8.16]
[ebuild UD] media-libs/libgd-1.8.3-r6 [2.0.12]
[ebuild U ] sys-libs/cracklib-2.7-r7 [2.7-r6]
[ebuild UD] dev-libs/libxml2-2.5.6 [2.5.7]
[ebuild N ] dev-php/php-4.3.2
matje@lambik matje $ emerge -p php
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild U ] sys-libs/cracklib-2.7-r7 [2.7-r6]
[ebuild N ] dev-php/php-4.3.2 |
_________________ Life is like a box of chocolates... Before you know it, it's empty... |
|
Back to top |
|
 |
Lion Apprentice


Joined: 23 Jun 2002 Posts: 207
|
Posted: Sun Jun 08, 2003 9:31 am Post subject: |
|
|
Matje wrote: | You might want to try emerge -U, without the -u flag. This way, only the packages necessary get installed, instead of telling portage to upgrade everything php depends of...
|
I don't think so. -U tells emerge to upgrade only, never to downgrade (and, as you can see from the example you just gave yourself, this is broken too!).
Furthermore, -U implies -u, so if you add -U to the options, you implicitly add -u as well. I don't have your setup, so please try the emerge -Up that you proposed, and see what that leads to.
Finally, you show that in your case emerge php would lead to the upgrade from cracklib 2.7-r6 to cracklib 2.7-r7. WHY??? I checked the php ebuild, and nowhere is specified that cracklib-2.7-r7 is necessary. As I said before, if I want all dependencies to be updated as well, I will use --deep! |
|
Back to top |
|
 |
Matje l33t

Joined: 29 Oct 2002 Posts: 619 Location: Hasselt, Belgium
|
Posted: Sun Jun 08, 2003 9:49 am Post subject: |
|
|
Code: | matje@lambik matje $ emerge -Up php
>>> --upgradeonly implies --update... adding --update to options.
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild U ] app-crypt/mhash-0.8.18-r1 [0.8.16]
[ebuild U ] sys-libs/cracklib-2.7-r7 [2.7-r6]
[ebuild N ] dev-php/php-4.3.2 |
I didn't realize that, but the -U flag does work properly. Because upgrade implies upgrade the package and all of it's direct dependency's, you get this output. However, I don't see cracklib and mhash in the ebuild either, but it are not deps of the two that are in there, readline and ncurses, so my best bet is that it has something to do with the inherit php option. This adds more dependency's I think (after all, the deps in the file are added to an existing $DEPEND, and so is the use-variable readline)...
--deep is used for dependency's of dependency's
I'm no developer either, talk to them for more info about this, I'm also just guessing here  _________________ Life is like a box of chocolates... Before you know it, it's empty... |
|
Back to top |
|
 |
Lion Apprentice


Joined: 23 Jun 2002 Posts: 207
|
Posted: Sun Jun 08, 2003 11:08 am Post subject: |
|
|
Matje wrote: |
I didn't realize that, but the -U flag does work properly. |
You are right in this case, I did not read your original post correctly.
But I have seen cases where -U definitely wanted to downgrade things. In my case, it was glibc, which led to quite some fun...
Matje wrote: |
Because upgrade implies upgrade the package and all of it's direct dependency's, you get this output. |
Exactly, and I think this is undesired behaviour.
Why would you always upgrade automatically direct dependencies if those upgrades are not necessary for the package you are upgrading?
If I'm using Gaim, and Gaim depends directly on Xfree, why then should I update a minor revision of Xfree that I would not otherwise think necessary when there is an update for Gaim, or have to jump through all kinds of hoops to prevent this?
Matje wrote: | --deep is used for dependency's of dependency's
|
Yes, and this is what I don't understand. Why not make --deep act for all dependencies, be it first level or multilevel? I see absolutely no advantage in the current behaviour of --update of automatically updating the first level of dependencies. |
|
Back to top |
|
 |
Loke Apprentice

Joined: 25 May 2002 Posts: 274 Location: Norway
|
Posted: Wed Jun 11, 2003 12:55 pm Post subject: |
|
|
I agree, updating -rX versions which quite clearly poses no real advantage beside the fancy new -rX extension is pointless really, and should only occure when you request it with --deep option. EDIT: I realize there _are_ changes in a package when they change the -rX number, but often these are just additional comments in a config file for example.
I believe a redesign of the --upgrade feature, together with a NEVER-TOUCH-THESE-PACKAGES-EVER (maybe a /usr/portage/profiles/package.protected file) list to put packages of your liking into would go along way to solve this problem.
Edit: typo
Last edited by Loke on Wed Jun 11, 2003 1:20 pm; edited 2 times in total |
|
Back to top |
|
 |
Loke Apprentice

Joined: 25 May 2002 Posts: 274 Location: Norway
|
Posted: Wed Jun 11, 2003 1:04 pm Post subject: |
|
|
Example of broken behaviour:
Code: |
# emerge -Uup world
These are the packages that I would merge, in order:
Calculating world dependencies ...done!
[ebuild U ] sys-kernel/ksymoops-2.4.9 [2.4.8]
[ebuild U ] sys-apps/e2fsprogs-1.33 [1.32-r2]
[ebuild U ] net-analyzer/nmap-3.27 [3.20]
[ebuild U ] dev-libs/libxslt-1.0.30 [1.0.29]
[ebuild U ] app-emulation/wine-20030508 [20030219]
[ebuild U ] dev-java/sun-jdk-1.4.1.02-r1 [1.4.1.02]
[ebuild U ] net-www/mozilla-1.3-r2 [1.3-r1]
[ebuild UD] sys-apps/acpid-1.0.1 [1.0.1-r1]
# emerge -Up world
>>> --upgradeonly implies --update... adding --update to options.
These are the packages that I would merge, in order:
Calculating world dependencies ...done!
[ebuild U ] sys-kernel/ksymoops-2.4.9 [2.4.8]
[ebuild U ] sys-apps/e2fsprogs-1.33 [1.32-r2]
[ebuild U ] net-analyzer/nmap-3.27 [3.20]
[ebuild U ] dev-libs/libxslt-1.0.30 [1.0.29]
[ebuild U ] app-emulation/wine-20030508 [20030219]
[ebuild U ] dev-java/sun-jdk-1.4.1.02-r1 [1.4.1.02]
[ebuild U ] net-www/mozilla-1.3-r2 [1.3-r1]
[ebuild UD] sys-apps/acpid-1.0.1 [1.0.1-r1]
#
|
Notice the
Code: |
>>> --upgradeonly implies --update... adding --update to options.
|
And _especially_ :
Code: |
[ebuild UD] sys-apps/acpid-1.0.1 [1.0.1-r1]
|
An upgrade request which in fact downgrades a package.
EDIT: While Im at it, lets take a look at my mozilla package. I see that portage wants to "upgrade" my mozilla package:
Code: |
[ebuild U ] net-www/mozilla-1.3-r2 [1.3-r1]
|
You'd expect id get a "better" mozilla by doing this right? At least thats what I think when I hear somethings being "upgraded" Well, here's a diff from the two ebuilds:
Code: |
# diff /usr/portage/net-www/mozilla/mozilla-1.3-r1.ebuild /usr/portage/net-www/mozilla/mozilla-1.3-r2.ebuild
3c3
< # $Header: /home/cvsroot/gentoo-x86/net-www/mozilla/mozilla-1.3-r1.ebuild,v 1.6 2003/05/22 04:25:42 azarah Exp $
---
> # $Header: /home/cvsroot/gentoo-x86/net-www/mozilla/mozilla-1.3-r2.ebuild,v 1.2 2003/06/09 19:26:02 brad Exp $
321,323c321,325
< export CFLAGS="${CFLAGS/-march=pentium4/-march=pentium3}"
< export CXXFLAGS="${CXXFLAGS/-march=pentium4/-march=pentium3}"
<
---
> if [ "$(gcc-minor-version)" -lt "3" ]; then
> replace-flags -march=pentium4 -march=pentium3
> filter-flags -msse2
> fi
>
#
|
This revision to the ebuild is most likely neccesary for people with an Intel P4 CPU - however, since Im on an AMD, do I benefit from letting my dual cpu rig compile for X hours? No, not at all. In fact, I can only think of negative aspects: I waste bandwith downloading mozilla (again), I waste rsync mirror bandwith, I waste cpu cycles and most importantly I waste alot of time. |
|
Back to top |
|
 |
Ssl Apprentice


Joined: 21 Feb 2003 Posts: 178 Location: Serbia
|
Posted: Thu Jun 12, 2003 8:09 am Post subject: |
|
|
Loke wrote: | I agree, updating -rX versions which quite clearly poses no real advantage beside the fancy new -rX extension is pointless really, and should only occure when you request it with --deep option. EDIT: I realize there _are_ changes in a package when they change the -rX number, but often these are just additional comments in a config file for example.
I believe a redesign of the --upgrade feature, together with a NEVER-TOUCH-THESE-PACKAGES-EVER (maybe a /usr/portage/profiles/package.protected file) list to put packages of your liking into would go along way to solve this problem.
Edit: typo |
There is solution (this is also said somewhere in userdocs/portage*) for NEVER-TOUCH-THESE-PACKAGES... your request.
Example:
If I do an Code: | emerge -p world | grep xfree | I see this:
Code: | [ebuild U ] x11-base/xfree-4.3.0-r3 [4.3.0-r1] |
I don't want to upgrade xfree-4.3.0-r1 to newer one, so I edited /var/cache/edb/world and added Code: | =x11-base/xfree-4.3.0-r1 |
Now with emerge -p world | grep xfree I see nothing !
As I know, this is working only for emerge world not for plain emerge <package_name>. Any comments?
Slobo |
|
Back to top |
|
 |
Matje l33t

Joined: 29 Oct 2002 Posts: 619 Location: Hasselt, Belgium
|
Posted: Thu Jun 12, 2003 8:50 am Post subject: |
|
|
Just inject the package, less hassle, and it works too when you try anything else as emerge world... _________________ Life is like a box of chocolates... Before you know it, it's empty... |
|
Back to top |
|
 |
Loke Apprentice

Joined: 25 May 2002 Posts: 274 Location: Norway
|
Posted: Thu Jun 12, 2003 6:36 pm Post subject: |
|
|
Slobo wrote: |
I don't want to upgrade xfree-4.3.0-r1 to newer one, so I edited /var/cache/edb/world and added Code: | =x11-base/xfree-4.3.0-r1 |
Now with emerge -p world | grep xfree I see nothing !
|
Matje wrote: |
Just inject the package, less hassle, and it works too when you try anything else as emerge world...
|
Both solutions work, but they really doesnt adress the problem. (I see them as quick-hacks btw) If I add a certain xfree ebuild flavour to the world file, I have to add it again when another ebuild is available in stable for example.
The solution to this, is whats mentioned earlier in this thread: Inject the package with a version number high above portages greedy grip, for example xfree-5.0. However, what then when xfree-5.0 is released? Like I said before, its a quick-hack, not a solution.
Both these methods are quick and dirty hacks. And after injecting X packages, do you really keep track after Y months or have you in reality lost control over what youve done in the past to your preciousss portage tree?
A NEVER-TOUCH-THESE-PACKAGES... list could just be:
Code: |
xfree
mplayer
nvidia-kernel
nvidia-glx
|
for example, and these ebuilds would _NEVER_ be touched - even if it meant upgrades in the future which does in fact require an xfree upgrade breaks. This list should _only_ be used by people who know what they are doing eg. "experts"
You could for example have a FEATURES="portage-protect-list" in /etc/make.conf, so you explicitly have to request this feature (much like prelinking for example). This way hopefully only people who know how to handle this, enables it
Comments? Perhaps its time to attract a developers attention to this thread? |
|
Back to top |
|
 |
deepthought Guru


Joined: 04 Apr 2003 Posts: 321 Location: icbm://5131''N:0710''E
|
Posted: Thu Jun 12, 2003 7:58 pm Post subject: |
|
|
Loke wrote: | Slobo wrote: |
I don't want to upgrade xfree-4.3.0-r1 to newer one, so I edited /var/cache/edb/world and added Code: | =x11-base/xfree-4.3.0-r1 |
Now with emerge -p world | grep xfree I see nothing !
|
Matje wrote: |
Just inject the package, less hassle, and it works too when you try anything else as emerge world...
|
Both solutions work, but they really doesnt adress the problem. (I see them as quick-hacks btw) If I add a certain xfree ebuild flavour to the world file, I have to add it again when another ebuild is available in stable for example.
|
Hm, I would disagree on this. When wanting to "pin" a package to a certain version (aka DONTEVERUPDATE), you *don't want* to update. Saying things like
is a perfectly safe solution for your problem. Btw, this is ubercustomizable: you can "pin" the package to a certain major/minor/rev version or say "I want foo, but I want it to be never greater/lighter/equal than v<something>".
This is certainly not a "quick-hack" as you stated above, but the real power of the Gentoo portage system.
Loke wrote: |
The solution to this, is whats mentioned earlier in this thread: Inject the package with a version number high above portages greedy grip, for example xfree-5.0. However, what then when xfree-5.0 is released? Like I said before, its a quick-hack, not a solution.
Both these methods are quick and dirty hacks. And after injecting X packages, do you really keep track after Y months or have you in reality lost control over what youve done in the past to your preciousss portage tree?
|
This is a *bad idea*. Noone (except for those guys being able to recite their package tree in reverse polish notation) will be able to track the changes on this. Note that starting this "inject frenzy" also can have unwanted side-effects: Injecting makes portage think a package is really there, so the deps for it are satisfied and so on... this can also badly break your installation.
Loke wrote: |
A NEVER-TOUCH-THESE-PACKAGES... list could just be:
Code: |
xfree
mplayer
nvidia-kernel
nvidia-glx
|
for example, and these ebuilds would _NEVER_ be touched - even if it meant upgrades in the future which does in fact require an xfree upgrade breaks. This list should _only_ be used by people who know what they are doing eg. "experts"
You could for example have a FEATURES="portage-protect-list" in /etc/make.conf, so you explicitly have to request this feature (much like prelinking for example). This way hopefully only people who know how to handle this, enables it
Comments? Perhaps its time to attract a developers attention to this thread? |
I would deem this unnecessary, because the "pin-version" feature of portage in the world file perfectly satisfies all your needs.
Regards,
Alexander _________________ Out of loyalty to its disregarded comrades, this message feels free to ignore the reader.
Registered Linux User #317705 |
|
Back to top |
|
 |
Loke Apprentice

Joined: 25 May 2002 Posts: 274 Location: Norway
|
Posted: Thu Jun 12, 2003 8:13 pm Post subject: |
|
|
Ok, if the "pin-feature" works they way you describe it, I agree it fits the needs I wanted, so thanks for pointing that out. I misunderstood this feature when it was mentioned before, since I didnt realize you _could_ lock a certain version from never being updated. |
|
Back to top |
|
 |
Genone Retired Dev


Joined: 14 Mar 2003 Posts: 9644 Location: beyond the rim
|
Posted: Fri Jun 13, 2003 12:26 am Post subject: |
|
|
There is already a bug for this: 16342. I'm really for it as I think the inject is an ugly workaround and the version-pinning never worked right for me. Well, at least I have now another item on my "things I wanna do to portage"-list. |
|
Back to top |
|
 |
deepthought Guru


Joined: 04 Apr 2003 Posts: 321 Location: icbm://5131''N:0710''E
|
Posted: Fri Jun 13, 2003 11:19 am Post subject: |
|
|
Hm, at least for me, version pinning works perfectly. What's wrong with it?
Regards,
Alexander _________________ Out of loyalty to its disregarded comrades, this message feels free to ignore the reader.
Registered Linux User #317705 |
|
Back to top |
|
 |
Loke Apprentice

Joined: 25 May 2002 Posts: 274 Location: Norway
|
Posted: Fri Jun 13, 2003 11:26 am Post subject: |
|
|
Not that Ive tried it yet, but wouldnt version pinning only work for world upgrades? It seems logical at least, and im pretty sure it does this by design - but is this what the requests in this thread deals with? |
|
Back to top |
|
 |
Genone Retired Dev


Joined: 14 Mar 2003 Posts: 9644 Location: beyond the rim
|
Posted: Fri Jun 13, 2003 11:49 am Post subject: |
|
|
deepthought wrote: | Hm, at least for me, version pinning works perfectly. What's wrong with it? |
Well, I only played with it a bit, I tried to pin my mozilla version to >=1.3 (which was ~x86 at that time) and that didn't work. Maybe I was expecting too much from this little feature. |
|
Back to top |
|
 |
Mnemia Guru


Joined: 17 May 2002 Posts: 476
|
Posted: Thu Jun 26, 2003 4:35 am Post subject: |
|
|
OK, here's a weird one for ya guys -
Code: |
luna root # emerge -pU world
>>> --upgradeonly implies --update... adding --update to options.
These are the packages that I would merge, in order:
Calculating world dependencies ...done!
[ebuild U ] media-gfx/gimp-1.2.4 [1.3.15] +python +nls +gnome +aalib +perl -doc +jpeg +png -tiff -doc
...
|
Why, oh why, is portage trying to downgrade gimp without popping up the little 'D' flag and thus allowing me to stop it from doing that when I use '-U' instead of '-u'? At first I thought this problem was occurring because the gimp version I have installed is in the ~x86 profile and I don't have ~x86 set in make.conf (I emerged it manually). But, I have done that exact thing with ~10 other packages and none of them have this problem. None of the others fail to show that flag. Is this a bug in the gimp ebuilds or just an example of horribly broken behavior in portage??
PS: I'm not going to be using --inject to fix this. As pointed out above, this risks breaking my system. And besides that's just a major hassle to keep track of all my own injected ebuilds just to cobble around portages' failure to properly track versions. If it doesn't work in all cases then -U is completely useless to me when doing an update world.
PPS: I've noticed this same problem a number of times lately. Methinks there are some major bugs lurking in the newer portage builds... |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|