Apps, libs and how are they organized the "arch way"?

nsg · 2014-08-29 21:07:13

Hi, I'm a rather new user in the Arch community so I'm sorry if this is obvious question, let me explain my problem.

I'm using both Kerberos and AFS to communicate with a computer club (and my old university) that I'm involved with. I see that nether of my favorite implementations (Heimdal and OpenAFS) are part of the official repositories. No problem I thought, always fun to learn to build a package, just one problem...

# pacman -Qi krb5 | grep Req
Required By    : cifs-utils  curl  dnsutils  lib32-krb5  libcups  libtirpc  neon  openssh  s-nail

I already have applications that require krb5, that's the MIT implementation of Kerberos, and the package contains all the user land binaries like kinit, klist and kadmin. I prefer the Heimdal ones, and I need the Heimdal kadmin to talk to the clubs Heimdal servers (KDC:s).

Sure, I could install Heimdal somewhere else and make sure the Heimdal binaries are before the MIT ones in PATH (like /usr/local) but that sounds like a ugly hack. In Debian based systems (that I'm used to) packages that require the kerberos libs are only depending on a package that contains the libs, for example openssh-client depends on libgssapi-krb5-2. No kinit, kadmin ... are installed so I'm free to install the Heimdal package for the user land tools, while for example ssh still uses the MIT libs that it is complained against.

Is this a common thing to package everything on one package in Arch? What is the recommended way to solve this?

karol · 2014-08-29 22:13:17

Both packages are in the AUR, heimdal is installed to /opt/heimdal but you can change this.
https://aur.archlinux.org/packages.php?K=heimdal
https://aur.archlinux.org/packages.php?K=openafs

I'm not sure if it's possible to chop krb5 into lib-only package. Maybe with some configure disable switch?

Leonid.I · 2014-08-29 23:02:29

nsg wrote:

Sure, I could install Heimdal somewhere else and make sure the Heimdal binaries are before the MIT ones in PATH (like /usr/local) but that sounds like a ugly hack. In Debian based systems (that I'm used to) packages that require the kerberos libs are only depending on a package that contains the libs, for example openssh-client depends on libgssapi-krb5-2. No kinit, kadmin ... are installed so I'm free to install the Heimdal package for the user land tools, while for example ssh still uses the MIT libs that it is complained against.
Is this a common thing to package everything on one package in Arch? What is the recommended way to solve this?

The right way to do this is to add conflicts=('krb5') and provides=('krb5') to heimdal's PKGBUILD and remove krb5 from your system.

Of course, this assumes that heimdal and MIT kerberos are compatible (so programs like curl and mutt will not notice a difference) -- I have never used either, so can not tell. Alternatively, one can try to install heimdal alongside krb5 by prepending binaries and libs from the former with "heimdal-", for instance.

Having said that, the heimdal-aur PKGBUILD looks really crappy -- don't use it unless you know what you are doing (I mean, who would install things to /opt?). I can probably fix it during the weekend...

EDIT: Oh, and to answer your general question about packaging of libs in ArchLinux, they are usually not split like in Debian. On the one hand, this makes packaging process simpler (fewer packages), but on the other hand, the packages become more bloated.

Last edited by Leonid.I (2014-08-29 23:05:37)

Allan · 2014-08-30 00:28:24

They are not compatible, so you can not just drop heimdal in. Also note that arch switched to krb5 from heimdal some time in the past.

nsg · 2014-08-30 08:25:56

Leonid.I wrote:

EDIT: Oh, and to answer your general question about packaging of libs in ArchLinux, they are usually not split like in Debian. On the one hand, this makes packaging process simpler (fewer packages), but on the other hand, the packages become more bloated.

This was the thing I was afraid of, I understand that it is easier to maintain packages and dependencies this way but it bloats that system with a lot of unnecessary applications. For example, if you never use Kerberos, why have all these binaries installed when it is only the libs you need. I was impressed when I installed Arch, how little that was installed by default. I was a Gentoo user back in the days and I really liked the idea to choose what to have on the system.

Leonid.I wrote:

The right way to do this is to add conflicts=('krb5') and provides=('krb5') to heimdal's PKGBUILD and remove krb5 from your system.
Of course, this assumes that heimdal and MIT kerberos are compatible (so programs like curl and mutt will not notice a difference) -- I have never used either, so can not tell. Alternatively, one can try to install heimdal alongside krb5 by prepending binaries and libs from the former with "heimdal-", for instance

Allan wrote:

They are not compatible, so you can not just drop heimdal in. Also note that arch switched to krb5 from heimdal some time in the past.

Thats true, the normal protocol is the same, but the libs and administrative tools differ. Yeah, it was a good choice for Arch to switch to the MIT libs, most applications are compiled against them these days. Heimdal is alive but the activity is extremely low, not that may that uses plain old Kerberos these days. The remaining activity is around MIT Kerberos.

So I see two was forward:

1. The easy route, create a package to install it to /usr/local. I agree that the heimdal-aur package looks crappy, I never intended to use that
or
2. Create a new package that only contains the libs from krb5, add conflicts=('krb5') and provides=('krb5') and install that. Hope that this will not break my system horrible and then create a proper package for Heimdal.

I think I will give alternative 2 a try, we will see if I beak my system

Thank you Leonid.I, Allan and karol for links/info. I will give this a try and report my findings.

nsg · 2014-08-30 14:04:15

nsg wrote:

I think I will give alternative 2 a try, we will see if I beak my system

Hehe, yeah, I broke my install a little. Forgot that the curl package also contains libcurl that is compiled against krb5. So I broke pacman when I did a pacman -Rdd krb5, ops I already had the PKGBUILD from the original package on disk so I used wget to download the tarball and compiled if from source, built a package and used the libs directly like this:

LD_LIBRARY_PATH=/home/nsg/build/packages/krb5/trunk/pkg/krb5/usr/lib pacman -S krb5

Back to square one again, time to move forward. I used the original PKGBUILD as inspiration and ended up with a package that works. It is hosted at GitHub at https://github.com/nsg/arch-lib64-krb5 and I would love some feedback. I build the package the exact same flags as the original krb5 package, I just remove the unwanted files after the compile. I also have implemented parallel compile, run the checks (with python2) and abort the build if it do not match the expected gpg signature.

After that, it was just a simple install:

# pacman -U /home/nsg/build/lib64-krb5/lib64-krb5-1.12.2-1-x86_64.pkg.tar.xz 
loading packages...
resolving dependencies...
looking for inter-conflicts...
:: lib64-krb5 and krb5 are in conflict. Remove krb5? [y/N] y

Packages (2): krb5-1.12.2-1 [removal]  lib64-krb5-1.12.2-1

Total Installed Size:   2.30 MiB
Net Upgrade Size:       -1.79 MiB

/../

... and pacman seems happy:

# pacman -Qi lib64-krb5
Name           : lib64-krb5
Version        : 1.12.2-1
Description    : The MIT Kerberos network authentication system libraries
Architecture   : x86_64
URL            : http://web.mit.edu/kerberos/
Licenses       : custom
Groups         : None
Provides       : krb5
Depends On     : e2fsprogs  libldap  keyutils
Optional Deps  : None
Required By    : cifs-utils  curl  dnsutils  lib32-krb5  libcups  libtirpc  neon  openssh  s-nail
Optional For   : None
Conflicts With : krb5
Replaces       : None
Installed Size : 2356.00 KiB
Packager       : Stefan Berggren <nsg@nsg.cc>
Build Date     : Sat 30 Aug 2014 03:40:39 PM CEST
Install Date   : Sat 30 Aug 2014 03:46:44 PM CEST
Install Reason : Explicitly installed
Install Script : No
Validated By   : None

Time to create a package for Heimdal

nsg · 2014-08-30 19:52:33

nsg wrote:

Time to create a package for Heimdal

All done, and everything works. Took most of the day to get it right but it was a good learning experience. Love some feedback, I think I have followed best practices and guidelines except the very un-archy way to build a lib64-package

https://aur.archlinux.org/packages/heimdal-krb-client/
https://aur.archlinux.org/packages/lib64-krb5/

I also took the time to upload the packages to AUR, always fun to share.

Allan · 2014-08-30 22:00:37

With provides/conflicts/replaces in option #2, you should not need an -Rdd. Just "pacman -U krb5-libs" and it will remove krb5 and install krb5-libs safely.

nsg · 2014-08-30 22:06:08

Allan wrote:

With provides/conflicts/replaces in option #2, you should not need an -Rdd. Just "pacman -U krb5-libs" and it will remove krb5 and install krb5-libs safely.

Indeed, that is what I did the 2nd time. I initially did the -Rdd to find out how broken the system was without krb5, so I had a good reference point to test out my new package from. The breakage of pacman was a surprise

Arch Linux

#1 2014-08-29 21:07:13

Apps, libs and how are they organized the "arch way"?

#2 2014-08-29 22:13:17

Re: Apps, libs and how are they organized the "arch way"?

#3 2014-08-29 23:02:29

Re: Apps, libs and how are they organized the "arch way"?

#4 2014-08-30 00:28:24

Re: Apps, libs and how are they organized the "arch way"?

#5 2014-08-30 08:25:56

Re: Apps, libs and how are they organized the "arch way"?

#6 2014-08-30 14:04:15

Re: Apps, libs and how are they organized the "arch way"?

#7 2014-08-30 19:52:33

Re: Apps, libs and how are they organized the "arch way"?

#8 2014-08-30 22:00:37

Re: Apps, libs and how are they organized the "arch way"?

#9 2014-08-30 22:06:08

Re: Apps, libs and how are they organized the "arch way"?

Board footer