| View previous topic :: View next topic |
| Author |
Message |
curmudgeon
Veteran
Joined: 08 Aug 2003
Posts: 1254
|
 Posted: Sat Apr 21, 2012 4:48 am Post subject: Is this the way portage is supposed to work? |
 |
|
| Code: |
# emerge -p vlc
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] media-video/ffmpeg-0.10.2 USE="X aac alsa ass bzip2 cdio encode gsm hardcoded-tables mmx mmxext mp3 network rtmp sdl speex ssse3 theora threads truetype vdpau vorbis xvid zlib -3dnow -3dnowext -aacplus (-altivec) -amr -avx -bindist (-celt) -cpudetection -debug -dirac -doc -faac -frei0r -gnutls -ieee1394 -jack -jpeg2k -libv4l -modplug (-neon) -openal -openssl -oss -pic -pulseaudio -schroedinger -static-libs -test -v4l -vaapi (-vis) -vpx -x264*" FFTOOLS="aviocat cws2fws ffeval graph2dot ismindex pktdumper qt-faststart trasher" 0 kB
[ebuild R ] media-video/vlc-1.1.13 USE="X a52 aac aalib alsa dbus directfb dvd fbcon ffmpeg flac fluidsynth fontconfig gcrypt ggi kde live matroska mmx mp3 mpeg ncurses ogg opengl png qt4 sdl speex sse svg theora truetype udev vorbis x264 xcb xml xv (-altivec) -atmo -avahi -bidi -cdda -cddb -dc1394 -debug -dirac -dts -dvb -gme -gnome -gnutls -httpd -id3tag -ieee1394 -jack -kate -libass -libcaca -libnotify -libproxy -libtiger -libv4l -libv4l2 -lirc -lua -modplug -mtp -musepack -nsplugin -optimisememory -oss -projectm -pulseaudio -pvr -remoteosd -rtsp -run-as-root -samba -schroedinger -sdl-image -shine -shout -skins -sqlite -stream (-svga) -taglib -twolame -upnp -v4l -vaapi -vcdx -vlm (-win32codecs) -wma-fixed -xosd -zvbi" 0 kB
Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
The following USE changes are necessary to proceed:
#required by virtual/ffmpeg-0.10.2-r1, required by media-video/vlc-1.1.13[-vaapi,ffmpeg], required by vlc (argument)
=media-video/ffmpeg-0.10.2 -x264
|
No, I don't want to recompile ffmpeg without x264 support.
| Code: |
# emerge -p ffmpeg
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] media-video/ffmpeg-0.10.2 USE="X aac alsa ass bzip2 cdio encode gsm hardcoded-tables mmx mmxext mp3 network rtmp sdl speex ssse3 theora threads truetype vdpau vorbis x264 xvid zlib -3dnow -3dnowext -aacplus (-altivec) -amr -avx -bindist (-celt) -cpudetection -debug -dirac -doc -faac -frei0r -gnutls -ieee1394 -jack -jpeg2k -libv4l -modplug (-neon) -openal -openssl -oss -pic -pulseaudio -schroedinger -static-libs -test -v4l -vaapi (-vis) -vpx" FFTOOLS="aviocat cws2fws ffeval graph2dot ismindex pktdumper qt-faststart trasher" 0 kB
Total: 1 package (1 reinstall), Size of downloads: 0 kB
velocious distfiles # emerge -Np vlc
These are the packages that would be merged, in order:
Calculating dependencies... done!
Total: 0 packages, Size of downloads: 0 kB
|
No problem here (virtual/ffmpeg is not checked).
| Code: |
# emerge -Np vlc
These are the packages that would be merged, in order:
Calculating dependencies... done!
Total: 0 packages, Size of downloads: 0 kB
|
Don't know what portage is doing here.
| Code: |
# emerge -DNp vlc
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] media-libs/jbigkit-2.0-r1 USE="-static-libs%" 0 kB
[ebuild R ] kde-base/kde-env-4.7.4 USE="(-aqua) (-kdeenablefinal%)" 0 kB
[ebuild R ] dev-libs/pth-2.0.7-r3 USE="-debug -static-libs%" 0 kB
[ebuild R ] kde-base/oxygen-icons-4.7.4 USE="(-aqua) -bindist (-kdeenablefinal%)" 0 kB
[ebuild R ] virtual/ffmpeg-0.10.2-r1 USE="X encode mp3 sdl theora threads truetype vdpau x264* -jpeg2k -vaapi" 0 kB
[ebuild R ] kde-base/kdelibs-4.7.4::local USE="alsa bzip2 fam handbook lzma mmx nls opengl policykit semantic-desktop spell sse sse2 ssl udev udisks upower -3dnow -acl (-altivec) (-aqua) -bindist -debug -doc -jpeg2k -kerberos -openexr -test -zeroconf (-kdeenablefinal%)" 0 kB
[ebuild R ] sys-auth/polkit-kde-agent-0.99.0 USE="(-aqua) -debug (-kdeenablefinal%)" LINGUAS="ru -ca -ca@valencia -cs -da -de -en_GB -eo -es -et -fi -fr -ga -gl -hr -hu -is -it -ja -km -lt -mai -ms -nb -nds -nl -pa -pt -pt_BR -ro -sk -sr -sr@ijekavian -sr@ijekavianlatin -sr@latin -sv -th -tr -uk -zh_TW" 0 kB
[ebuild R ] kde-base/katepart-4.7.4 USE="handbook (-aqua) -debug (-kdeenablefinal%)" 0 kB
[ebuild R ] kde-base/nepomuk-4.7.4::local USE="handbook (-aqua) -debug (-kdeenablefinal%)" 0 kB
[ebuild R ] kde-base/kdesu-4.7.4 USE="handbook (-aqua) -debug (-kdeenablefinal%)" 0 kB
[ebuild R ] kde-misc/polkit-kde-kcmodules-0.98_pre20101127 USE="(-aqua) -debug (-kdeenablefinal%)" 0 kB
[ebuild R ] kde-base/khelpcenter-4.7.4::local USE="(-aqua) -debug (-kdeenablefinal%)" 0 kB
[ebuild R ] sys-libs/glibc-2.13-r4::local USE="glibc-omitfp (multilib) -debug -gd (-hardened) -profile (-selinux) -vanilla (-nls%*)" 0 kB
[ebuild R ] sys-devel/gcc-4.5.3-r2 USE="cxx fortran gcj gtk mudflap (multilib) nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -graphite (-hardened) (-libssp) -lto -multislot -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla (-libffi%)" 0 kB
Total: 14 packages (14 reinstalls), Size of downloads: 0 kB
|
Sure, I want to reinstall a bunch of packages with changed (irrelevant) use flags - including glibc and gcc.
Yes, I know what I need to do to fix this, but somehow the logic just seems completely borked. Why doesn't portage suggest reinstalling the virtual with the flags of the real package rather than recompiling the package? And the handling of the "N" use flag (in this instance) just defies any logic that I can see. I know this stuff is not trivial, but it seems to me that it should work a lot better than it does. |
|
| Back to top |
|
 |
BoneKracker
Veteran
Joined: 14 Mar 2006
Posts: 1487
Location: U.S.A.
|
| Posted: Sun Apr 22, 2012 12:04 am Post subject: |
|
|
Because the flags on the virtual are supposed to drive the flags on the actual package, not vice-versa.
_________________
Oldthinkers unbellyfeel INGSOC.
-- Headline of a document on Winston Smith's terminal in his cubicle at the Ministry of Truth, seen briefly in the background in one scene of the movie rendition of Nineteen Eighty-Four. |
|
| Back to top |
|
|
curmudgeon
Veteran
Joined: 08 Aug 2003
Posts: 1254
|
| Posted: Sun Apr 29, 2012 2:11 pm Post subject: |
|
|
| BoneKracker wrote: | | Because the flags on the virtual are supposed to drive the flags on the actual package, not vice-versa. |
Seems backwards to me (and this example illustrates why). |
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 7610
|
| Posted: Sun Apr 29, 2012 4:29 pm Post subject: |
|
|
The flags on the packages that use ffmpeg drive the flags on virtual/ffmpeg, which in turn drives the flags on the installed ffmpeg. If the flags on media-video/ffmpeg drove the flags on virtual/ffmpeg, then the virtual would in turn drive the flags on the packages you want to use. You would still need to adjust USE flags to get a working dependency tree, so I prefer to set the USE flags I want on the package I want, then let the package manager tell me what other changes are required to achieve that.
If it worked in reverse, the package manager would be telling me that I must undo changes I want to satisfy the flags on the underlying library, even though I do not care what USE flags are on media-video/ffmpeg, so I do not mind if I must change them. |
|
| Back to top |
|
|
curmudgeon
Veteran
Joined: 08 Aug 2003
Posts: 1254
|
| Posted: Sun May 20, 2012 4:25 am Post subject: |
|
|
| Hu wrote: | | The flags on the packages that use ffmpeg drive the flags on virtual/ffmpeg, which in turn drives the flags on the installed ffmpeg. |
I am still not understanding this. If what you say is the case, the USE=x264 flag should suggest reinstalling virtual/ffmpeg with USE=x264.
| Hu wrote: | | I prefer to set the USE flags I want on the package I want, then let the package manager tell me what other changes are required to achieve that. |
That is what (I thought) I did. I set USE=x264, but the package manager told me I couldn't have it, rather than "tell[ing] me what other changes are required to achieve that." |
|
| Back to top |
|
|
BoneKracker
Veteran
Joined: 14 Mar 2006
Posts: 1487
Location: U.S.A.
|
| Posted: Sun May 20, 2012 5:19 am Post subject: |
|
|
If you are confused, look at the ebuild. You can pretty quickly sort out what the effects are of enabling any particular USE flag.
_________________
Oldthinkers unbellyfeel INGSOC.
-- Headline of a document on Winston Smith's terminal in his cubicle at the Ministry of Truth, seen briefly in the background in one scene of the movie rendition of Nineteen Eighty-Four. |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 3140
|
| Posted: Sun May 20, 2012 5:55 am Post subject: |
|
|
The problem here is not the package manager but that the <virtual/ffmpeg-0.10.3 ebuilds are broken: Just because vlc is compiled without x264 support, it should not force ffmpeg compiled without this support. This should only be true for enabling such support. Apparently, this has been fixed in =virtual/ffmpeg-0.10.3.
Concerning looking at ebuilds: For ebuilds with huge eclasses this may be rather inconvenient, I suggest using >=eix-0.25.0[dep] to find out about dependencies: | Code: | | eix -vl virtual/ffmpeg |
shows why the two virtual/ffmpeg's act so differently. |
|
| Back to top |
|
|
BoneKracker
Veteran
Joined: 14 Mar 2006
Posts: 1487
Location: U.S.A.
|
| Posted: Sun May 20, 2012 6:33 am Post subject: |
|
|
| mv wrote: | The problem here is not the package manager but that the <virtual/ffmpeg-0.10.3 ebuilds are broken: Just because vlc is compiled without x264 support, it should not force ffmpeg compiled without this support. This should only be true for enabling such support. Apparently, this has been fixed in =virtual/ffmpeg-0.10.3.
Concerning looking at ebuilds: For ebuilds with huge eclasses this may be rather inconvenient, I suggest using >=eix-0.25.0[dep] to find out about dependencies: | Code: | | eix -vl virtual/ffmpeg |
shows why the two virtual/ffmpeg's act so differently. |
Or app-portage/gentoolkit (/usr/bin/equery), or app-portage/portage-utils (/usr/bin/qdepends, and /usr/bin/qgrep can be handy too).
So I guess the answer is, "No, portage is not supposed to work this way." 
_________________
Oldthinkers unbellyfeel INGSOC.
-- Headline of a document on Winston Smith's terminal in his cubicle at the Ministry of Truth, seen briefly in the background in one scene of the movie rendition of Nineteen Eighty-Four. |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 3140
|
| Posted: Sun May 20, 2012 9:15 am Post subject: |
|
|
| BoneKracker wrote: | | Or app-portage/gentoolkit (/usr/bin/equery), or app-portage/portage-utils (/usr/bin/qdepends, and /usr/bin/qgrep can be handy too). |
Currently, neither gentoolkit nor portage-utils can output the actual dependency strings - this is the main reason why this was built into eix.
| Quote: | | So I guess the answer is, "No, portage is not supposed to work this way." |
I would say quite the opposite  But it works of course only nice if the dependencies are correctly specified (which was not the case in virtual/ffmpeg). |
|
| Back to top |
|
|
BoneKracker
Veteran
Joined: 14 Mar 2006
Posts: 1487
Location: U.S.A.
|
| Posted: Mon May 21, 2012 12:18 am Post subject: |
|
|
If you really must see the actual dependency strings, then you can use qgrep, or just look at the ebuild (the search functions of any editor make that pretty easy to do).
But if you don't mind having eix on your system (say, because you are constantly searching the portage tree for packages and prefer not to do it using one of several web sites which allow you to this without having a load of crap on your system for that purpose alone), and you don't mind waiting for eix to update its index every time you sync portage, then its a good tool to use for this purpose. It's a popular tool, but some people prefer not to use it.
_________________
Oldthinkers unbellyfeel INGSOC.
-- Headline of a document on Winston Smith's terminal in his cubicle at the Ministry of Truth, seen briefly in the background in one scene of the movie rendition of Nineteen Eighty-Four. |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 3140
|
| Posted: Mon May 21, 2012 5:29 am Post subject: |
|
|
| BoneKracker wrote: | | If you really must see the actual dependency strings, then you can use qgrep, or just look at the ebuild (the search functions of any editor make that pretty easy to do). |
This is only partially true. Many dependencies come implicitly through eclasses and are not easy to spot (e.g. dependencies on autotools, python, various vcs eclasses, ...). Some other packages even mainly rely on eclasses (kde, gnome, texlive). To make sure that you did not miss anything you must either read a lot of shell code very carefully or (much easier) look at the produced metadata which is what you can do e.g. with eix. Of course, you might also look up the metadata files manually, but this is inconvient if you do it often. |
|
| Back to top |
|
|
BoneKracker
Veteran
Joined: 14 Mar 2006
Posts: 1487
Location: U.S.A.
|
| Posted: Mon May 21, 2012 5:58 am Post subject: |
|
|
| mv wrote: | | BoneKracker wrote: | | If you really must see the actual dependency strings, then you can use qgrep, or just look at the ebuild (the search functions of any editor make that pretty easy to do). |
This is only partially true. Many dependencies come implicitly through eclasses and are not easy to spot (e.g. dependencies on autotools, python, various vcs eclasses, ...). Some other packages even mainly rely on eclasses (kde, gnome, texlive). To make sure that you did not miss anything you must either read a lot of shell code very carefully or (much easier) look at the produced metadata which is what you can do e.g. with eix. Of course, you might also look up the metadata files manually, but this is inconvient if you do it often. |
I stand corrected. But you can see everything with equery, and use qgrep for targeted searches for actual strings. And the 'q' utilities are fast.
| Code: | ~ # equery depends ffmpeg
* These packages depend on ffmpeg:
media-libs/gegl-0.2.0 (ffmpeg ? virtual/ffmpeg)
media-libs/libpostproc-0.8.0.20120229 (>=virtual/ffmpeg-0.10.2-r2)
media-video/vlc-2.0.1 (avcodec ? virtual/ffmpeg)
(avformat ? virtual/ffmpeg)
(postproc ? media-video/ffmpeg)
(swscale ? virtual/ffmpeg)
virtual/ffmpeg-0.10.3 (>=media-video/ffmpeg-0.10.3[X?,encode?,jpeg2k?,mp3?,sdl?,theora?,threads?,truetype?,vaapi?,vdpau?,x264?]) |
I tend to be a minimalist and get a twitch in my face when I perceive there to be something redundant or unnecessary on one of my machines. I understand that eix is a popular, useful tool.
_________________
Oldthinkers unbellyfeel INGSOC.
-- Headline of a document on Winston Smith's terminal in his cubicle at the Ministry of Truth, seen briefly in the background in one scene of the movie rendition of Nineteen Eighty-Four. |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 3140
|
| Posted: Mon May 21, 2012 6:10 am Post subject: |
|
|
| BoneKracker wrote: | | But you can see everything with equery |
Not really. For instance, the main point of virtual/ffmpeg is that you can use libav instead of ffmpeg. The equery output gives no hint about tihs: It looks as if ffmpeg were a mandatory dependency (and AFAIK there is no other equery command which would show you this "||").
| Quote: | | I tend to be a minimalist and get a twitch in my face when I perceive there to be something redundant or unnecessary on one of my machines. |
You might write a script which looks up metadata in the metadata files. However, this can be rather complex, since now metadata can be stored in many places in different ways, and this is what eix was particularly made for. |
|
| Back to top |
|
|
BoneKracker
Veteran
Joined: 14 Mar 2006
Posts: 1487
Location: U.S.A.
|
| Posted: Mon May 21, 2012 6:22 am Post subject: |
|
|
| Code: | ~ # equery depgraph -U virtual/ffmpeg
* Searching for ffmpeg in virtual ...
* dependency graph for virtual/ffmpeg-0.10.2-r1
`-- virtual/ffmpeg-0.10.2-r1 x86
`-- media-video/ffmpeg-0.10.3 (>=media-video/ffmpeg-0.10.2) ~x86
`-- media-video/libav-0.8.2-r2 (>=media-video/libav-0.8.2) ~x86
[ virtual/ffmpeg-0.10.2-r1 stats: packages (3), max depth (1) ]
* dependency graph for virtual/ffmpeg-0.10.3
`-- virtual/ffmpeg-0.10.3 ~x86
`-- media-video/ffmpeg-0.10.3 (>=media-video/ffmpeg-0.10.3) ~x86
`-- media-video/libav-0.8.2-r2 (>=media-video/libav-0.8.2-r2) ~x86
[ virtual/ffmpeg-0.10.3 stats: packages (3), max depth (1) ] |
_________________
Oldthinkers unbellyfeel INGSOC.
-- Headline of a document on Winston Smith's terminal in his cubicle at the Ministry of Truth, seen briefly in the background in one scene of the movie rendition of Nineteen Eighty-Four. |
|
| Back to top |
|
|
steveL
Veteran
Joined: 13 Sep 2006
Posts: 1670
Location: The Peanut Gallery
|
| Posted: Mon May 21, 2012 7:34 am Post subject: |
|
|
| BoneKracker wrote: | you can see everything with equery, and use qgrep for targeted searches for actual strings. And the 'q' utilities are fast.
..
I tend to be a minimalist and get a twitch in my face when I perceive there to be something redundant or unnecessary on one of my machines. I understand that eix is a popular, useful tool. |
This makes no sense to me: you like q because it's fast, but prefer equery for general queries like this. equery is slow as fsck, ime, and eix is quick like er q ;)
The only thing you've said that counts against eix is the need to run eix-sync after emerge --sync, and I can sympathise, which is why update runs it for me automatically when I update -s (if you have eix that is; I personally find the display of changes in the tree to be a very useful indication of how fast things are moving), but if you have portage-utils, you must have set up /etc/portage/postsync.d/q-reinitialize so I don't get why you didn't just add a file in there to eix-sync?
Having said that, I've always used equery depends for reverse dependency lookup. I find all three useful: eix for when I need to lookup a package, qlist and qfile are the ones I use most from portage-utils, and as I said equery for dep lookups.
I've never got very far with eix beyond that: there's a lot of stuff it can do, I know, but I gave up after 2 or 3 attempts to read the manpage. I know it does loads, but I've never really needed it; I respect the approach though, since it really is an excellent tool for querying the tree, and the power is there if you do need it.
The only other thing I use it for is getting the description of a package: | Code: | | d=$(eix -n "$pN"|sed -n '/.*Description:[[:space:]]*/ {s///p;q;}') |
and then only if we can't extract it myself from the ebuild (either ebuild is missing, or we couldn't find the description, which should not happen ofc, or it uses a variable description.) OFC, if you don't have eix, it falls back to q, which is a hard dep.
Thinking about, I'm going to switch that to using the metadata cache, since not regenerating it, but syncing from the server has been a default for a couple of years (I used to set it manually, and was advised not to rely on the cache; I don't think any devs are using update somehow.. ;) |
|
| Back to top |
|
|
BoneKracker
Veteran
Joined: 14 Mar 2006
Posts: 1487
Location: U.S.A.
|
| Posted: Mon May 21, 2012 7:55 am Post subject: |
|
|
Okay, okay, I give up! eix is the greatest thing since sliced bread, and everybody should be using it, including me. 
_________________
Oldthinkers unbellyfeel INGSOC.
-- Headline of a document on Winston Smith's terminal in his cubicle at the Ministry of Truth, seen briefly in the background in one scene of the movie rendition of Nineteen Eighty-Four. |
|
| Back to top |
|
|
steveL
Veteran
Joined: 13 Sep 2006
Posts: 1670
Location: The Peanut Gallery
|
| Posted: Mon May 21, 2012 8:06 am Post subject: |
|
|
| BoneKracker wrote: | | Okay, okay, I give up! |
lol that's what I like to hear ;-)
Use what you want, guy. |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 3140
|
| Posted: Mon May 21, 2012 8:14 am Post subject: |
|
|
| BoneKracker wrote: | | Code: | | ~ # equery depgraph -U virtual/ffmpeg |
|
Thanks, I was not aware that depgraph could show ||. If I knew, probably eix would not know DEP-metadata still... ;)
| steveL wrote: | | The only other thing I use it for is getting the description of a package |
Better to use only eix without sed/grep and hacks to suppress further matches and color:
| Code: | | d=$(eix --brief --pure-packages --format '<description>' "${pN}") |
(Better, because the user might have changed the default settings of eix, and then things might horribly break.) |
|
| Back to top |
|
|
steveL
Veteran
Joined: 13 Sep 2006
Posts: 1670
Location: The Peanut Gallery
|
| Posted: Tue May 22, 2012 6:06 pm Post subject: |
|
|
| mv wrote: | | steveL wrote: | | The only other thing I use it for is getting the description of a package |
Better to use only eix without sed/grep and hacks to suppress further matches and color:
| Code: | | d=$(eix --brief --pure-packages --format '<description>' "${pN}") |
(Better, because the user might have changed the default settings of eix, and then things might horribly break.) |
Ah lovely thanks mv :D I'll incorporate that change as the new fallback, though I'm going to look up in the cache first, which should mean the fallback is needed even more infrequently.
I've never been very good with eix: the manpage is a lot to get your head round, but --format is very useful. eg earlier today I worked out | Code: | | eix --stable --format '<bestversion:NAMEVERSION>' |
and | Code: | | eix --testing --format '<bestversion:NAMEVERSION>' |
to get a list of what's available in stable and unstable. |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 3140
|
| Posted: Tue May 22, 2012 7:19 pm Post subject: |
|
|
| steveL wrote: | | Code: | | eix --testing --format '<bestversion:NAMEVERSION>' |
to get a list of what's available in stable and unstable. |
Probably here you mean | Code: | | eix --testing --format '<bestversion*:NAMEVERSION>' |
(with * after bestversion) so that actually the unstable version number is displayed.
Or maybe you want to use even bestslotversions [resp. bestslotversions*] to see also whether several slots of the same package are stable/unstable. Of course, then perhaps you also might see the slot and thus use something like
| Code: | | A='<name>-<version>{slots}:<slot>{}\n' eix --testing --format '<bestslotversions*:A>' |
(And I hope that now you understand why the eix manpage is so complicated... ) |
|
| Back to top |
|
|
steveL
Veteran
Joined: 13 Sep 2006
Posts: 1670
Location: The Peanut Gallery
|
| Posted: Tue May 22, 2012 8:06 pm Post subject: |
|
|
| mv wrote: | Probably here you mean | Code: | | eix --testing --format '<bestversion*:NAMEVERSION>' |
(with * after bestversion) so that actually the unstable version number is displayed. |
Heh, yeah just discovered that, and was going to correct it :)
| Quote: | Or maybe you want to use even bestslotversions [resp. bestslotversions*] to see also whether several slots of the same package are stable/unstable. Of course, then perhaps you also might see the slot and thus use something like
| Code: | | A='<name>-<version>{slots}:<slot>{}\n' eix --testing --format '<bestslotversions*:A>' |
(And I hope that now you understand why the eix manpage is so complicated... ;) ) |
Heh I do now ;-) We're actually trying to get a list of just the best-visible versions, so what we have (adding * for testing) is okay I think, but the use of a variable like that will be very handy for a versionsimple property (see end.)
The current script is:
| Code: | #!/bin/sh
# $Id: distrowatch.sh,v 1.2 2008/07/12 02:02:47 robbat2 Exp $
# this file creates a list of packages from the Portage tree for distrowatch
#
# $1 = web script directory
# $2 = web site htdocs directory
if ! [ -d "$1" -a -d "$2" ]; then
echo "You must specify the path to the web scripts and the path to the website htdocs directory"
exit 1
fi
#Note: distrowatch lists non-x86 packages like yaboot, so I'm now including all arches (drobbins, 04/04/2003)
STABLE_ARCHES=" x86 amd64 ppc alpha arm hppa ia64 m68k mips ppc64 s390 sh sparc sparc-fbsd x86-fbsd"
UNSTABLE_ARCHES=" ~x86 ~amd64 ~ppc ~alpha ~arm ~hppa ~ia64 ~m68k ~mips ~ppc64 ~s390 ~sh ~sparc ~sparc-fbsd ~x86-fbsd"
# gentoo_pkglist_x86.txt contains the stable branch packages
ACCEPT_KEYWORDS="$STABLE_ARCHES" $1/pkglist.py 1> $2/dyn/gentoo_pkglist_x86.txt 2> /dev/null
# gentoo_pkglist_X86.txt contains the unstable branch packages (note capital X)
ACCEPT_KEYWORDS="$STABLE_ARCHES $UNSTABLE_ARCHES" $1/pkglist.py 1> $2/dyn/gentoo_pkglist_X86.txt 2> /dev/null |
and the helper (pkglist.py) is:
| Code: | #!/usr/bin/python
# $Id: pkglist.py,v 1.1 2005/11/24 23:45:54 ramereth Exp $
import portage
allpkgs=portage.db["/"]["porttree"].dbapi.cp_all()
bestpkgs={}
mycount=0
for x in allpkgs:
if x not in bestpkgs.keys():
y=portage.db["/"]["porttree"].dbapi.xmatch("bestmatch-visible", x)
bestpkgs[x]=y
if y=="":
continue
xs=portage.pkgsplit(bestpkgs[x])
print xs[0].split("/")[1],
print xs[1],
print bestpkgs[x]
mycount+=1 |
which is very slow: hence my suggestion to use eix in place of pkglist.py as it's so fast (and add exec eix-sync -q -0 -N to a sh-script in /etc/portage/postsync.d).
There's two issues: first we just want the version, without the gentoo revision. I couldn't find a property for that under FORMATSTRING so just piping via sed -E 's/-r[0-9]+$//' for the moment; an enhancement bug-report for eix can then be filed for a versionsimple or simpleversion property (or the equivalent), where your variable example above would come in handy, if there weren't a NAMEVERSIONSIMPLE as well.
The other is whether the ACCEPT_KEYWORDS setting will be used by eix, as we need ebuilds across all the arches. I'm hoping it would; certainly local portage settings are in effect by default (and have to be switched off.) I just don't know if that includes the arch settings: still that can always be tested by output comparison.
Re-reading that, it seems they must be used. It's just something I'd want to verify properly via diff -u (or cmp in script.)
Thanks for sharing your knowledge :) |
|
| Back to top |
|
|
steveL
Veteran
Joined: 13 Sep 2006
Posts: 1670
Location: The Peanut Gallery
|
| Posted: Tue May 22, 2012 11:51 pm Post subject: |
|
|
Well the problem doesn't matter any more, as it would have to be run every time the cache were updated, and only then, and would have to give names of ebuilds in portage tree only (no overlays.) The problem is if you do --only-in-overlay 0 then it excludes any package which is in an overlay, and if you do --in-overlay 0 it gives the best version from any overlay. I think both is equivalent to the former, but I don't have any overlays. | Code: | | --format '{overlaynum=""}<bestversion*:NAMEVERSION>{}' |
would be nice (I don't know if '{<property>}' means =="" or !="" since the spec is {[!]property[=rhs]}) but man eix says it "must occur only in VARIABLE in the context of version printing" which is a shame. |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 3140
|
| Posted: Wed May 23, 2012 4:22 pm Post subject: |
|
|
| steveL wrote: | | first we just want the version, without the gentoo revision. |
For eix, the version always contains the revision number: eix is not a package manager, so this distinction would make no sense for eix.
| Quote: | | The other is whether the ACCEPT_KEYWORDS setting will be used by eix. |
Yes, they will. Actually, you can even set ARCH to several arches for eix (which is perhaps not supported by portage).
| Quote: | | (I don't know if '{<property>}' means =="" or !="" |
It means != "" (in analogy with perl).
| Quote: | | must occur only in VARIABLE in the context of version printing |
It makes only sense in the context of version printing: The same package may have versions in different overlays; even the same version-number (of the same package) might occur in different overlays (and e.g. be marked stable in one overlay but marked testing in another overlay); eix considers these as different versions, although the version-numbers are the same. |
|
| Back to top |
|
|
steveL
Veteran
Joined: 13 Sep 2006
Posts: 1670
Location: The Peanut Gallery
|
| Posted: Wed May 23, 2012 6:12 pm Post subject: |
|
|
| mv wrote: | | For eix, the version always contains the revision number: eix is not a package manager, so this distinction would make no sense for eix. |
Well it's still a useful piece of information, eg for a user or script wanting to check whether there are newer versions of a package/s available from upstream. Your argument (it's not a package manager) could equally apply to version and slot, or (exaggerated) why even split the name and version? Basically it's the standard $PV which is used far more often in ebuilds than $PVR which is what eix outputs as VERSION (full gentoo version, which is obviously more generally useful in end-user context.) So I guess the variable requested is PV, not versionsimple or anything ;-)
But no, it's not hard to extract, as the sed snippet showed, though to be safe that'd have to deal with prefix inter-revisions which isn't needed for this usage. It's not tricky, but it's something else to get wrong, and requires an ERE or two sed commands. So it becomes more useful as a general setting for a script, making the extraction simple and much more efficient (which is where eix really shines.)
| Quote: | | Quote: | | The other is whether the ACCEPT_KEYWORDS setting will be used by eix. |
Yes, they will. Actually, you can even set ARCH to several arches for eix (which is perhaps not supported by portage). |
That's good to know; and with the unstable arches there, --testing doesn't need bestversion*.
Yeah, it is supported by portage, as the original script shows.
| Quote: | | Quote: | | must occur only in VARIABLE in the context of version printing |
It makes only sense in the context of version printing: The same package may have versions in different overlays; even the same version-number (of the same package) might occur in different overlays (and e.g. be marked stable in one overlay but marked testing in another overlay); eix considers these as different versions, although the version-numbers are the same. |
Yes, but once you've found the best-visible, that has to be from a specific overlay. I've coded the same algorithm in bash for update.
But yeah, it's understandable that one wouldn't want to special-case that instance.
_________________
| creaker wrote: | | systemd. It is a really ass pain |
update - "a most excellent portage wrapper"
#friendly-coders -- We're still here for you™ ;) |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 3140
|
| Posted: Wed May 23, 2012 8:02 pm Post subject: |
|
|
| steveL wrote: | | Your argument (it's not a package manager) could equally apply to version and slot, or (exaggerated) why even split the name and version? |
eix has to know all these data e.g. to sort for versions, decide for upgrades etc., but eix has no reason for a finer treatment of the revision string.
However, it is trivial to implement, so now there are "plainversion" and "revision" attributes in the current eix git master on BerlioS (>=eix-0.25.6).
Moreover, also the versionsort utility now supports -p and -r options (so that you could use also that in place of sed).
| Quote: | | Basically it's the standard $PV which is used far more often |
Yes, within ebuilds. But eix is not a package manager, so it has nothing to do with ebuild variables like $PV.
| Quote: | | Yeah, it is supported by portage, as the original script shows. |
I really meant the ARCH variable not the ACCEPT_KEYWORDS variable.
| Quote: | | Yes, but once you've found the best-visible, that has to be from a specific overlay. |
And so you can output it: | Code: | | A='best <category>/<name> is from {overlaynum}<overlaynum>{else}main tree{}\n' eix --format '<bestversion:A>' |
Actually you can even store it in a runtime variable and output it later: | Code: | | A='{*ov=<overlaynum>}' eix --format '<bestversion:A>Best <category>/<name> is from {$ov}<$ov>{else}main tree{}\n' |
|
|
| 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
|
|
Portage & Programming
