pkg and packages

Matthew Seaman m.seaman at
Wed May 3 15:53:56 UTC 2017

On 2017/05/03 15:53, Chris H wrote:
> On Wed, 03 May 2017 08:03:36 -0400 <scratch65535 at> wrote
>> After doing a general pkg upgrade on my server-of-all-work, I
>> discovered after some research that the Big Grey Background I was
>> left with  was due to pkg having deleted, but not replaced, xfce4
>> desktop.

This is an annoying effect when it happens unexpectedly.  However, I
can't see how pkg(8) could behave otherwise.  What happens is that if
you say:

    pkg install foo

pkg(8) works under the quite reasonable impression that you want foo
installed.  Now, if foo conflicts with another package you have
installed, say 'bar', then pkg(8) will deinstall bar as an essential
step towards getting foo installed.

In general, this is what you would want to happen.  'Conflicts' here
means either that the packages in question each install one or more
files of the same name as one from the other package, or that one
installs a shared library with an ABI version that matches the other

The problem from your point of view is that as an intelligent being you
see samba44 and samba46 as essentially different versions of the same
thing.  pkg(8) (all appearances to the contrary) is not at all
intelligent, and can only treat the two different samba packages as
completely distinct things.

What would be great is if we could give a list of alternates as
dependencies when creating packages, but unfortunately the packaging
system does not have that capability.  Yet.

>> Trying to install the desktop package, I discovered that it's
>> bundled with at least 2 unrelated pieces of software:  Thunar,
>> and samba44.  That bothered me, but I needed the desktop.

'Bundling' isn't the right term -- Thunar and samba44 are /dependencies/
of the xfce4-desktop.  That is: other packages that need to be installed
before the package in question will work.  Sorting out dependency trees
like this is much of what pkg(8) exists for.

>> pkg got totally confused during the install, first downloading 44
>> and THEN noticing the conflict with 46.  So it downloaded 46,
>> too(!), deleted the existing 46, installed 44, and then tried to
>> re-install 46, failing with a complaint because it had just
>> installed 44 and that created a conflict.
>> But it gets better.  Trying to reinstall the samba46 package, I
>> discovered that I'd have to sacrifice the desktop that I just
>> installed.
>> Clearly, no good can come of packaging unrelated software
>> together, so there needs to be a way to prevent that, or at least
>> criticise those who do it.
>> And pkg should (a) check for later versions *before* downloading
>> older ones, (b) preferably not install old versions over newer
>> without explicit permission, and (c) as a fallback should allow
>> packages to be decomposed at install time such that installation
>> is not a yes/no all-or-nothing choice.
> In pkg(8)'s humble defense; it simply *expedites* your request.
> It isn't the QA dept. for [port] Maintainers.
> Mind you; I *fully* appreciate your position. I'm simply trying to
> indicate *where*, or at *whom* to point fingers. :-)

Yes, indeed.  pkg(8) does have a tendency to do exactly what you tell
it, and sometimes that is not what you would intuitively expect.

The thing that seems to trip most people up is thinking they can
substitute some other package instead of the exact dependency listed in
the package metadata.  This is not an unreasonable request, especially
when you know your alternate package does exactly the same thing as the
one you want to replace.  Unfortunately it just doesn't work right now,
and it would take quite a lot of disruptive change in the ports tree and
to pkg(8) itself to make that happen.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 972 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the freebsd-ports mailing list