Alternative to portversion

ikbendeman

ikbendeman

Is there another way to get a list similar to when running "portversion | grep '<'" because it seems silly to me to install portupgrade just to use portversion... I use portmaster and make install clean to install everything anyways. On a related note, why does everyone like portupgrade so much more than portmaster, and why are you not supposed to use both of them together? Does this mean if you're using portupgrade you're also not supposed to make install clean?
 
For the first question, you can use # pkg_version | grep '<', which I believe is part of the base system. It'll probably take longer as it has to check each package against the available port, whereas the portupgrade tools keep a database.

Portupgrade has been around considerably longer and, short answer, there are a lot of people who are just more familiar with its usage than portmaster and don't have a reason to switch (or just prefer how portupgrade works). The biggest reason I can think of to not use both in conjunction would be because of the way they each separately track dependencies. But you shouldn't have to worry about installing new ports with the # make install clean method. That shouldn't cause any problems regardless of whether you use portupgrade or portmaster.
 
From man portversion(1):
portversion is very similar to pkg_version(1), but is optimized for
portupgrade(1) and runs much faster than pkg_version(1) thanks to the
ports database generated from the INDEX file. See portsdb(1) for
details.
Click to expand...

The usage between the two is similar.

pkg_version -vl '<'
pkg_version -vL '='
 
If you always have an up-to-date INDEX- file in /usr/ports (e.g. portsnap updates it), you can use pkg_version -IvL '=' (well, that's what I use anyway).

Code: 
     -I, --index-only
             Use only the index file for determining if a package is out of
             date.  This is much faster than using the version number from a
             port's Makefile, at the expense of potentially giving an incor-
             rect result if the index file is out of date.

I doubt portversion will be 'much faster' than that.
Code: 
# pkg_info | wc -l 
     613

# time pkg_version -IvL '='

real	0m0.330s (that's 1/3rd of a second, yes)
user	0m0.291s
sys	0m0.037s
 
DutchDaemon said:
If you always have an up-to-date INDEX- file in /usr/ports (e.g. portsnap updates it), you can use pkg_version -IvL '=' (well, that's what I use anyway).

Code: 
     -I, --index-only
             Use only the index file for determining if a package is out of
             date.  This is much faster than using the version number from a
             port's Makefile, at the expense of potentially giving an incor-
             rect result if the index file is out of date.
Click to expand...

Been doing just that for several years now, however with the recent Mesa updates, [red]-vIL=[/red] gives poor answers:
Code: 
> pkg_version -vIL=
dri-7.6.1,2                         >   succeeds index (index has 7.4.4,2)
libGL-7.6.1                         >   succeeds index (index has 7.4.4)
libGLU-7.6.1                        >   succeeds index (index has 7.4.4)
libGLw-7.6.1                        >   succeeds index (index has 7.4.4)
libdrm-2.4.17                       >   succeeds index (index has 2.4.12)
libglut-7.6.1                       >   succeeds index (index has 7.4.4)
mesa-demos-7.6.1                    >   succeeds index (index has 7.4.4)

I suppose [cmd=""]pkg_version -vIL"=>"[/cmd] is the answer to that . . .
 
Well, that's the price you pay for installing newer stuff than the ports tree itself has .. I've never seen this type of message myself.
 
DutchDaemon said:
Well, that's the price you pay for installing newer stuff than the ports tree itself has .. I've never seen this type of message myself.
Click to expand...

WITHOUT_NOUVEAU will get you GL/Mesa that is ahead for the version numbers in the index, since 7.4.4 and 7.6.1 both install from the same port(s) (also with drm 2.4.17).

[cmd=""]pkg_version -vL=[/cmd] & [cmd=""]pkg_version -vIL=[/cmd] give different answers if you have WITHOUT_NOUVEAU set, oddly enough. If you unset it, [red]-vL=[/red] & [red]-vIL=[/red] suddenly agree again.
 
It's a setting required in /etc/make.conf*, if you (cf /usr/ports/UPDATING, specifically the section
Code: 
20100207:
  AFFECTS: users of Mesa3D libraries and x11-drivers/xf86-video-nouveau
  AUTHOR: nork@FreeBSD.org

  If you want to use Mesa3D 7.6.1 and libdrm 2.4.17 rather than 7.4.4
  and 2.4.12, you must define WITHOUT_NOUVEAU global macro, at least,
  enabled on graphics/libGL*, graphics/libglut, graphics/dri,
  graphics/mesa-demos, and graphics/libdrm.  And please give up using
  x11-drivers/xf86-video-nouveau.

  At this time, I cannot enable latest Mesa3D and libdrm, because they
  break xf86-video-nouveau.  But old (current?) Mesa3D and libdrm do not
  break any drivers.

  AMD Radeon HD 2xxx/3xxx/4xxx users: If you use AMD Radeon HD [234]xxx
  series, please define WITHOUT_NOUVEAU global macro.  You can then use
  OpenGL Hardware Accelerator feature on these series.
)
Hopefully, it'll get massaged out over the next few weeks/months, so the WITHOUT_NOUVEAU hack can go the way of XFREE86_VERSION & X_WINDOW_SYSTEM.



*the more I think about it, you could just set it specifically for the ports in question, but it seems harmless enough in /etc/make.conf
 
You must log in or register to reply here.
Back
Top