pkg and packages
bapt at FreeBSD.org
Thu May 4 12:18:06 UTC 2017
On Thu, May 04, 2017 at 08:09:47AM -0400, scratch65535 at att.net wrote:
> On Wed, 3 May 2017 16:53:41 +0100, Matthew Seaman
> <m.seaman at infracaninophile.co.uk> wrote:
> >>> 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.
> I can't imagine what code could possibly be in thunar and samba
> that the xfce desktop would need, particularly since the desktop
> is very simple, and also because I've never got samba
> functionality for free after installing xfce which if you're
> right I should have done. But I'll check on that, and report
> That kind of tight coupling at the macro level *is* a very
> serious problem for the ports system, though. It's strangling
> How many ports just build, first go? Are there *any*? I suspect
> not. And yet the maintainers presumably thought they would.
> I stopped trying to build ports because I could never get a make
> to run to completion. There was always at least one dependency
> that (a) couldn't be found at all, (b) was the wrong version, or
> (c) failed compilation. That didn't happen when I was writing
> stuff under sco or sys v.
> It shouldn't happen with our ports system, either, because it
> completely prevents code freeze and stability, a basic
> requirement for high-quality software. The stuff being fetched
> from Timbuktu or somebody's cat's litter box should be cleaned
> up, built into a library, and be fetched from there subsequently.
> There should never be a dependency on code that the ports project
> doesn't control.
> >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.
> You call it "disruptive" change, but from here it looks exactly
> like *healthy*, *professional* change. Really.
There is no garanty the libsmb.so.X provided by samba44 is binary compatible
with the one from samba46 this is why there is a strong dependency here.
For more defaly look at my answer here
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the freebsd-ports