Arch Linux

blippy

Member

Registered: 2010-11-18

Posts: 38

PKGBUILD review request: neoleo

I'm trying to create a package for neoleo. Here is my PKGBUILD file:

# Maintainer: Mark Carter <alt.mcarter@gmail.com>
pkgname=neoleo
pkgver=3.0.1
pkgrel=1
pkgdesc="Fork of the GNU oleo lightweight spreadsheet"
arch=('i686' 'x86_64')
url="https://github.com/blippy/neoleo"
license=('GPL')
optdepends=()
source=("https://github.com/blippy/neoleo/releases/download/v$pkgver/$pkgname-$pkgver.tar.gz")
md5sums=('802229a004de2c4a4b0efea78355f655')


build() {
        cd "$pkgname-$pkgver"
        ./configure --prefix=/usr
        make
}

        
package() {
        cd "$pkgname-$pkgver"
        make DESTDIR="$pkgdir/" install
}

Is it OK?

Last edited by blippy (2016-11-29 09:18:02)

Slithery

Administrator

From: Norfolk, UK

Registered: 2013-12-01

Posts: 5,776

Re: PKGBUILD review request: neoleo

Does it really have no dependencies at all? - Hint

---

No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

blippy

Member

Registered: 2010-11-18

Posts: 38

Re: PKGBUILD review request: neoleo

There might be some optional make dependencies like X11 header files. Should that be specified in PKGBUILD?

It has an optional dependency on the XBae - but that's a tricky one. xbae exists in AUR, but it is dependent on openmotif. The problem is, almost everyone else uses lesstif, which is a conflicting package. So although xbae exists, it is unlikely to be useful to those who care most.

I actually have lesstif package installed on my system, which means I can't install xbae from AUR.  I do have xbae on my system, but I compiled it from source to circumvent the conflict.

So neoleo should compile using either lesstif or openmotif, provided xbae is available. It's difficult to know what the best way forward is.

eschwartz

Fellow

Registered: 2014-08-08

Posts: 4,097

Re: PKGBUILD review request: neoleo

It's not difficult at all. If the package compiles and works using the stated dependencies, it is okay. An excellent way to test this is to use makechrootpkg from devtools (used for building the repo packages).

According to your README, this PKGBUILD will simply refuse to compile and exit with errors, if the user does not magically know they need those undocumented packages.
Compile-time selections are NOT "optional".
Header files are supposed to be packaged together with their runtime libraries, which by definition are kind of not "make dependencies"... so I am thinking X11 isn't optional either, nor a makedepends...

Your only options are:
- Configure with the "--without-x" switch referenced in that README.
- Choose one and stick with it. Feel free to make multiple PKGBUILDs to work with multiple ways of configuring it.
- Use a variable in the PKGBUILD to allow users to choose a backend and modify the depends appropriately. Be aware that that sort of thing is frowned upon.
- Upload an "xbae-lesstif" package or suchlike, and depend on that

...

Question (I know nothing about these packages):
You make it sound like xbae works with either lesstif or openmotif, and neoleo needs xbae as well as either lesstif or openmotif. Is there a problem with just letting users get their xbae however they darn well please, rather than moralizing over your specific preference? Surely anyone who wants xbae+openmotif can fork the PKGBUILD just like you did, assuming you don't share yours and save them the trouble.

---

Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

blippy

Member

Registered: 2010-11-18

Posts: 38

Re: PKGBUILD review request: neoleo

I'll look into the makechrootpkg - I hadn't heard of the tool before.

XBae is optional. The package will build without it. The configure.ac script works out if it can compile in the extras. I decided to uninstall lesstif, install openmotif, and install the existing xbae package from AUR.

I have therefore added xbae as an optdepends. One thing confuses me, though: it is possible to uninstall an optdepends package, and pacman won't complain about the dependent package. This is bad, because a needed library is removed. I need to be able to say "if you do decide to install xbae, you can't remove it afterwards".

Here's what I've got so far:

# Maintainer: Mark Carter <alt.mcarter@gmail.com>
pkgname=neoleo
pkgver=3.0.1
pkgrel=1
pkgdesc="Fork of the GNU oleo lightweight spreadsheet"
arch=('i686' 'x86_64')
url="https://github.com/blippy/neoleo"
license=('GPL')
depends=('ncurses')
optdepends=('xbae')
source=("https://github.com/blippy/neoleo/releases/download/v$pkgver/$pkgname-$pkgver.tar.gz")
md5sums=('802229a004de2c4a4b0efea78355f655')


build() {
        cd "$pkgname-$pkgver"
        ./configure --prefix=/usr
        make
}


package() {
        cd "$pkgname-$pkgver"
        make DESTDIR="$pkgdir/" install
}

eschwartz

Fellow

Registered: 2014-08-08

Posts: 4,097

Re: PKGBUILD review request: neoleo

What you just described is xbae not being optional. Optional means at runtime either you or the package itself can choose whether to use it.

Either tell configure "for the love of G-d, ignore what is on the system and don't even *think* of compiling with xbae", or xbae must be a dependency, no ifs ands or buts.

Software that silently changes what shared libraries it links to depending on what is installed on the system is the bane of packaging. There are no solutions, ever, other than not allowing it to decide. And filing a bugreport upstream for inappropriate behavior (which I suppose I have just done).
i.e. the configure script should default to a constant, not to something dynamically calculated from the build system.

Last edited by eschwartz (2016-11-29 18:52:30)

---

Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

alphaniner

Member

From: Ancapistan

Registered: 2010-07-12

Posts: 2,810

Re: PKGBUILD review request: neoleo

Software that silently changes what shared libraries it links to depending on what is installed on the system is the bane of packaging.

Thanks for that, now I feel better about feeling aghast when I found that this is exactly what samba does (did?) WRT cups. Though, my aghastitude was more to do with how much research I had to do to figure that out.

OTOH, it was that experience which got me building everything in a clean chroot.

@blippy sorry for OT

Last edited by alphaniner (2016-11-29 18:59:59)

---

But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner

blippy

Member

Registered: 2010-11-18

Posts: 38

Re: PKGBUILD review request: neoleo

What you just described is xbae not being optional. Optional means at runtime either you or the package itself can choose whether to use it.

Ah, I see.

Either tell configure "for the love of G-d, ignore what is on the system and don't even *think* of compiling with xbae", or xbae must be a dependency, no ifs ands or buts.

OK, now I get it. In that case, I'll mandate the use of xbae, because I really like that feature.

Software that silently changes what shared libraries it links to depending on what is installed on the system is the bane of packaging. There are no solutions, ever, other than not allowing it to decide. And filing a bugreport upstream for inappropriate behavior (which I suppose I have just done).
i.e. the configure script should default to a constant, not to something dynamically calculated from the build system.

Ah, I see. I didn't realise. I see at
https://wiki.gentoo.org/wiki/Project:Qu … pendencies
"automagic dependencies are wrong"

It's been a learning experience for me!

eschwartz

Fellow

Registered: 2014-08-08

Posts: 4,097

Re: PKGBUILD review request: neoleo

It's been a learning experience for me!

Well, that is the important thing, isn't it.

---

Managing AUR repos The Right Way -- aurpublish (now a standalone tool)