Official FreeBSD Binary Packages now available for pkgng

[Polytropon]

On Thu, 31 Oct 2013 07:41:14 +0000, Matthew Seaman wrote:
> On 31/10/2013 04:11, Polytropon wrote:
> > On Wed, 30 Oct 2013 20:59:54 -0700, David Newman wrote:
> >>
> >>
> >> On 10/30/13 7:10 PM, Bryan Drewery wrote:
> >>
> >>> You can now either continue to use ports with portmaster/portupgrade, as
> >>> before or switch to using binary packages only.
> >>
> >> Is this really an "or" or is it an "and"?
> >>
> >> For example, can a system use binary packages for most things, but use
> >> portmaster or portupgrade on those ports where some special config
> >> options are needed?
> > 
> > To extend the question, does the traditional method of using
> > ports (without portmaster et al.) also seem to stop working?
> > I'd like to emphasize that the constellation you mentioned
> > isn't that uncommon. Take mplayer, for example; in order to
> > make it work properly (i. e., all codecs plus mencoder), it's
> > still required to compile it. My idea would be that I can
> > use pkg to install everything that's needed as a runtime
> > dependency, and only have a "make install" run for mplayer
> > with a custom Makefile.local (or going through "make configure"
> > for that matter). Localized ports (e. g. LibreOffice with
> > german language) could also fall into the category of "still
> > needs compiling"...
> > 
> > To be honest, there may be only a few things that need a
> > manual "make install" run, but those could actually be
> > essential. How does this interact with a system that uses
> > pkg for all other needs? The old pkg_* tools worked well
> > in such a constellation, even though it might be required
> > to recompile some dependent ports (according to the non-
> > default options that have been chosen), but in general,
> > that was no big deal.
> > 
> > Will it start being a problem now?
> 
> No, mixing binary packages from pkg.freebsd.org with locally compiled
> customized versions should work, so long as reasonable care is taken to
> use a local ports tree of similar age to the ports tree used for
> building the official packages.

I've done that in the past, either by using RELEASE packages
and a RELEASE ports tree (usually from the installation CD),
or Latest/ packages and an updated ports tree.



> You can do this with
> portmaster(8)/portupgrade(8) or by setting up your own instance of
> poudriere(8) or even just 'cd /usr/ports/foo/bar ; make all install'

Correct, that constellation has been working. Of course it
was important to use "pkgdb -aF" (portupgrade) whenever
pkg_add or "make install" has been called. Even portmaster
with the -P and -PP switches worked. As you said, being
careful on _how_ to properly do this is essential.



> Making this sort of mix of local customized and official packages work
> really well is one of our (pkg(8) developers) top aims.  The integration
> at the moment should be a bit better than using the old pkg_tools
> packages in this way, but there are even more improvements yet to come.

I'm _very_ happy to hear that. Thanks! :-)



> There are also changes afoot which will have the effect of reducing the
> number of options on individual packages but compensating by increasing
> the number of packages to cover the different options settings.  This is
> what sub-packages is all about: many options do little more than add a
> few extra files to the pkg-plist: those can easily be hived off into a
> separate sub-package.

That's true. Especially for things like mplayer there is a
remarkable slew of dialogs when you "make config-recursive"
to make sure everything has been selected as required to
gain the "full functionality". Of course it will not be
possible to offer every imaginable combination of options
for all packages, but it would be a very helpful thing if
one could use pkg for everything except the few programs
that one _really_ needs and intends to compile, be it
because of codecs or because of applying non-default
optimization flags (again, mplayer on older machines is
such a candidate).



Again, many thanks for your explanations. I can't wait
to actually try the constellation I've described on my
old 500 MHz K6 "service laptop". :-)




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