pkg and packages

[Baptiste Daroussin]

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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20170504/8c835da0/attachment.sig>