Re: Anti-bundling materials

[Jason Bacon <outpaddling%yahoo.com@localhost>]

On 8/21/21 9:48 AM, Jason Bacon wrote:
> On 8/21/21 8:49 AM, J. Lewis Muir wrote:
> > On 08/20, Jason Bacon wrote:
> > > Does pkgsrc have a document somewhere similar to the following?
> > >
> > > https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries 
> > >
> > > https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
> > > https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
> > > https://docs.freebsd.org/en/books/porters-handbook/special/#bundled-libs
> > >
> > > I've had some positive responses sharing these links with upstream
> > > developers.  Also some silence, but never a negative response.  ;-)
> > > Increasing the size of the chorus might make it more convincing, though.
> >
> > I assume you include in this the non-C/C++ library case too, right?  (To
> > me, the language the dependency is written in makes no difference; the
> > issues are the same.)
> >
> > The practice of bundling (a.k.a. vendoring) is rampant in the Java and
> > Ruby world.  And, not speaking from experience, it seems similar in the
> > Node.js, Go, and Rust world, to name a few more.  FYI, it was discussed
> > in January on pkgsrc-users at
> >
> >    https://mail-index.netbsd.org/pkgsrc-users/2021/01/22/msg033148.html
> >
> > Unfortunately, the conclusion seemed to be that separately packaging all
> > of the dependencies was unworkable. :-(
> >
> > I think it might be possible if the process of creating packages for
> > the dependencies was 100% automated.  But even if successful with that,
> > there's a second problem: getting upstreams to adopt a configurable
> > approach to be able to use externally supplied dependencies rather than
> > the bundled/vendored dependencies that they've been written for.
> >
> > Lewis
>
> I'm not suggesting that bundling/vendoring should be forbidden in all 
> cases, just that we can help discourage poor practices among upstream 
> developers.  Of course it's impossible to unbundle everything.
>
> In the case of GO modules, it's not really bundling in the sense 
> discussed in these links.  GO dependencies are separate projects, but 
> they're downloaded and inserted into the source tree at build time.
>
> What we're talking about here is things like copying a C library into an 
> application's source dist, which then falls behind the mainstream 
> version that may already be available as a pkgsrc package.  This 
> practice is common in scientific software and leads to security issues 
> and other bugs that are difficult to fix because the software uses an 
> outdated API.
>
> If we add our voice to the chorus, we might convince a few more upstream 
> developers to stop doing this and our job as packagers will become a 
> little easier.
>
> It's just a matter of posting a small document that might nudge some 
> developers in the right direction.

If we don't have such a document, I'd be happy to write something up. 
I'd be inclined to make it a section in the pkgsrc guide.