Debian discusses vendoring—again

Posted Jan 13, 2021 21:48 UTC (Wed) by lkppo (guest, #97462)
In reply to: Debian discusses vendoring—again by kleptog
Parent article: Debian discusses vendoring—again

That sounds like a good alternative. Another solution would be to have scripts to automatically bulk package the libraries of node, pip, composer, etc. managers in DEB format, independently of the applications that use them. All that remains for the application maintainer is to use the dependencies he needs and possibly plug the holes.

Debian discusses vendoring—again

Posted Jan 14, 2021 3:34 UTC (Thu) by pabs (subscriber, #43278) [Link]

The problem with language ecosystem packages is that they often differ from the upstream VCS repo, sometimes even missing source code or build tools to build some generated files.

That said, there are already tools to convert language ecosystem packages to Debian source packages. I think Debian needs to go further than that and integrate more of those things into debhelper and similar.

https://wiki.debian.org/AutomaticPackagingTools

Debian discusses vendoring—again

Posted Jan 14, 2021 14:34 UTC (Thu) by pj (subscriber, #4506) [Link] (1 responses)

The other problem is that debian enforces 'one version of a thing' while other package managers don't - npm, for example, lets every package have its own dependency sub-tree, so there may be multiple versions of the same package in use (even major versions, so they have different APIs!). Fixing this for debian requires the version-in-the-name hack, which isn't too bad, but figuring out which packages _need_ this fix might be more difficult. I guess Debian could package them all with the major version, maybe with a kind of 'realm' prefix: npmlib-foojs-1 for foojs v1.x.

Debian discusses vendoring—again

Posted Jan 26, 2021 4:42 UTC (Tue) by calumapplepie (guest, #143655) [Link]

The central issue is that we don't want to have multiple versions of a package, even when we can. Putting the version in the name is long-established practice for core packages that have major versions: it's the best way to handle upgrades, for instance. However, tracking three different versions of a package means that security and bugfix support becomes almost impossible: we now need to backport fixes not once, but many times.

The fact that apt doesn't permit per-package dependency trees is intentional. We don't want duplicate (or nearly-duplicate) files on our systems, our mirrors, or our security trackers. NPM's ability to let you have a dozen versions of every package just leads to headaches when you need to update one.