Why i need extract not one needed port, but full catalog never needed ports?

Polytropon freebsd at edvax.de
Fri Sep 6 11:12:21 UTC 2019

On Fri, 06 Sep 2019 09:41:04 +0100, Mike Clarke wrote:
> On Thursday, 5 September 2019 22:22:20 BST @lbutlr wrote:
> > AFAIK, there’s no real good way to integrate a pkg install and a ports install.
> It works quite well if you sync your ports tree against the version
> used for the current pkg repository.

It does, but you have to do one of the following whenever your
build options are different from the port's standard options:

a) use "pkg lock" and "pkg unlock" in case of a pkg-based upgrade,
   and rebuild your custom port from synced-again sources, or

b) use poudriere to create a custom repository which pkg uses
   when performing the upgrade.

Depending on _how many_ custom ports you have, one solution is
more convenient than the other. Also always keep in mind that
introducing a non-standard feature (i. e., enabling one in
"make config" that is not selected for the default configuration)
might have an effect on other ports, either introducing new
dependencies, or requiring another port to be built with a
custom option.

But that is nothing basically new, it was almost the same in
ye olden times when portmaster and the pkg_* tools roamed the
FreeBSD software ecosystem. ;-)

> I have a couple of packages which I build from ports because
> I need different options for one of them and the licensing
> prevents the distribution of a binary for the other. I have
> no problems building and installing them when I sync the ports
> tree against the pkg repository.

Exactly that is the typical case where "pkg install" from the
default repository is not a solution.

> An ideal alternative would be if the package system could have
> a command which would return the SVN revision of the ports tree
> used for building the current repository.

That would be helpful. Checking out that particular version would
be easier than grepping in ports' revision histories...

By the way, this would probably fill the gap that portdowngrade
left behind, i. e., when you know that version 1.2.7 was the last
usable version of a particular program, but 1.8.1 is current, and
you want to build 1.2.7 - either with the current version of the
rest of the ports tree, or with the version that matched _that_
(older) version number, could be maybe because it contained libraries
that have been removed in a later version of the tree.

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

More information about the freebsd-questions mailing list