Re: Building native packages with pkgsrc (was: Re: pkgsrc-based Linux distribution)

[Jason Bacon <bacon4000%gmail.com@localhost>]

On 08/10/17 17:59, Mikhail T. wrote:
> Picking up on the conversation archived here:
>
>     https://mail-index.netbsd.org/tech-pkg/2013/04/10/msg011065.html
>
> Aleksey Cheusov wrote:
> > we [pkgsrc] should provide yum repository for RHEL, zypper repos for 
> > SLES, apt repositories for Debian derivatives etc.
> I agree with the above rather strongly -- pkgsrc should not be "all or 
> nothing". It offers a far superior way to /build/ packages on most 
> OSes, but there is no justification for it replacing the native 
> package-managers.
>
> Myself a happy user of FreeBSD ports, I'm now tasked with setting up 
> package-building for Ubuntu and would much rather use pkgsrc, than 
> anything Ubuntu/Debian offer. But the resulting packages, however I 
> build them, must be installable on a generic Ubuntu system, playing 
> well with the packages installed through other channels.
The part about "playing well with packages installed through other 
channels" makes this a huge can of worms.  You simply can't guarantee 
compatibility (versions, build options, etc.) with packages from a 
separate repository.  Even if a package works today, it could be broken 
by the next yum/apt update.  Everything may appear to be fine at install 
time, but you end up with users discovering problems at run-time due to 
API changes in a shared lib that was updated since your program was 
compiled against it, changes in command interfaces, etc.  I still use 
EPEL and a couple other 3rd party repos occasionally, where the cost of 
using another method outweighs the risk, but I keep it to a minimum, so 
I can focus on productive tasks instead of emergency firefighting sessions.

One of the things I like best about pkgsrc is the fact that I can keep 
it separated from Yum (without forcing every user into a container).  I 
don't have to try to make modern open source software work with the 
outdated compilers and libraries provided by RHEL/CentOS.  RHEL does 
this for good reasons, like long-term binary compatibility for 
commercial software and system stability.  It's nothing to gripe about, 
but it does present a problem for keeping open source software 
up-to-date.  Pkgsrc solves this problem very nicely.

For our pkgsrc trees, we use an environment module that scrubs the env 
(PATH, LD_LIBRARY_PATH, etc.) to ensure that pkgsrc users get minimal 
interference from software installed by other methods.

I'll add that I can bootstrap a pkgsrc tree in about 6.5 minutes:

Linux tianpar.cs  bacon ~ 64: (pkgsrc): time auto-pkgsrc-setup

============================================================================
Default responses are shown in [].  Simple press Enter to accept defaults.

Type Ctrl+c at any time to stop installation.
============================================================================

[ snip ]

============================================================================
For more information, go to http://www.netbsd.org/docs/pkgsrc/
============================================================================

182.957u 93.216s 6:28.26 71.1%  0+0k 0+2347176io 0pf+0w

If I'm using a prefix for which there are binary package (/usr/pkg, 
/sharedapps/pkg-####Q#), I can install almost anything with pkg_add or 
pkgin in seconds.

> > Obviously we should _not_ use /usr as a prefix for many reason. 
> This is the part I do not consider "obvious" at all. But, as long as 
> the prefix remains configurable, there is no need to agree on the 
> single location...

Many makefiles, configure scripts, etc. have /usr hard-coded as a search 
path for dependencies.  This occasionally causes pkgsrc builds to fail 
on systems that install add-on software into /usr, because the wrong 
version of a command or lib from outside pkgsrc leaks into the build.  
For this reason, I now build my CentOS packages in a chroot env with 
only GCC added on top of the CentOS-minimal install.  Once, built, the 
packages isolate themselves well using rpath, etc., so installing them 
on a system full of Yum packages is not problematic.

--
Earth is a beta site.