On Thu, May 04, 2017 at 08:09:47AM -0400, scratch65...@att.net wrote: > On Wed, 3 May 2017 16:53:41 +0100, Matthew Seaman > <m.sea...@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 > back. > > That kind of tight coupling at the macro level *is* a very > serious problem for the ports system, though. It's strangling > it. > > 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219036 Bapt
signature.asc
Description: PGP signature