tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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.




Home | Main Index | Thread Index | Old Index