Combining pkg and "traditional ports"

[Polytropon]

NOTE: Re-sending the message to the list, hope that's okay.
      Google refuses to accept e-mail from my IP (probably
      whole range of ISP due to "an unusual rate of 550-5.7.1
      unsolicited mail originating from your IP address" -
      definitely not from _my_ *current* IP. :-)

On Wed, 15 Jan 2014 01:07:13 -0500, Jim Ohlstein wrote:
> Hello,
> 
> On 1/15/14, 12:36 AM, Polytropon wrote:
> > With the upcoming OS standardization on pkg (pkgng) following
> > the abolishment of the pkg_* toolset I'd like to ask questions
> > to those who already actively use pkg and have probably encountered
> > and solved the same "problems" that I'll be expecting:
> >
> > There are two cases where a binary package can't be used:
> >
> > a) There is no package.
> >
> > Not all ports have equivalent packages. For example, I've seen
> > this recently for OpenArena. In this case, compiling is needed
> > (and even switching to gcc instead of clang, OS v10-RC2). Another
> > example is a localize OpenOffice / maybe LibreOffice.
> >
> > How is this handled when a pkg-based "upgrade all" is performed?
> >
> > b) The default options of the package can't be used.
> >
> > My favourite example is mplayer (including all imaginable
> > codecs as well as mencoder and additionally the gmplayer
> > and gmencoder X applications), but it could also apply for
> > a HAL-less X and HAL-less applications. But also OpenOffice
> > can be considered again, a localized version (german) with
> > dependencies for KDE, Gnome and CUPS deactivated (because I
> > don't use those).
> >
> > Can those be protected from being overwritten?
> 
> # pkg lock package_name
> 
> You probably will need to unlock the package to upgrade via the port.

Of course I will always keep packages and the ports tree up
to date, so their versions should match as close as possible.
The locking method seems to be a good measure against acci-
dental overwriting (with default options, which might break
things functionally and/or organizationally).



> > Is there even a method of saying, like, "use binary packages
> > to upgrade everything excepts ports 'foo', 'bar', 'meow' and
> > 'moo', compile those, but make sure their dependencies are
> > installed via packages when they are available and apply"?
> 
> I think if you only use "pkg lock" on the packages that you want to 
> compile, running "pkg upgrade" will upgrade all others for which there 
> is an upgrade is a binary package, including dependencies of packages 
> that you have compiled.

That is what I've intend. I wish to only compile those which
_intendely_ need compiling, those are usually the "top ports"
and maybe _some_ of their dependencies (e. g. those which need
to be compiled with HAL disabled).



> Be aware though, that if you haven't "locked" a 
> package, running "pkg upgrade" will suggest to you to upgrade to 
> versions of installed packages with the "default" options.

That would probably be the same version as in the updated ports
tree, so _after_ compiling and installing it that way, the
version checks should perform correctly.



By the way, do you know if it will still be possible to use
tools like portdowngrade to install programs in older versions,
because their newer versions lost functionality that I need?
A good example is the xzgv image viewer where version 0.8_9
is the last usable one, but requires GTK version 1 (just like
XFCE 3, the excellent "CDE lookalike", which has been removed
from ports).




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...