[solved] PKGBUILD for .deb

kalsan · 2017-07-29 08:40:14

Hi forum,

I can't find a guide how to write PKGBUILDs for .deb files and I'm still pretty unexperienced with building PKGBUILDs. I'm trying to build one for Craftware and it's working fine, but namcap is not happy with me and lots of things are unclear to me:
-> All the opt files are "outside of a valid path" but appearently the .deb wants to use the /opt folder. How should I react?
-> It sais that EULA is not a valid license, but I can't find a proprietary license in /usr/share/licenses/common/
-> This is 32bit software and it will very likely depend on multilib. How should I indicate that in the PKGBUILD?
-> Right now I'm dealing with permissions in the package() but I need to reference the parent folder to use chmod or chown. Is this the proper way to do it?

Here's my PKGBUILD so far:

# Maintainer: My-name-here

pkgname=craftware
pkgver=1.14
pkgrel=1
pkgdesc="A FREE, fast, easy-to-use slicer software that converts your digital 3D object into a .gcode toolpath format understood by most 3D printers."
arch=('i686' 'x86_64')
url="https://craftunique.com/craftware/"
license=('EULA')
depends=()
#install='craftware.install'
source=('https://craftware.craftunique.com/download/linux/CraftWare_1.14')
md5sums=('1ee23de9534934d2bf7a35bcbd19812e')

package() {
	tar -xf data.tar.xz -C "${pkgdir}"
	chown root:root -R ../pkg/craftware/opt
	chmod 755 -R ../pkg/craftware/opt
	chown root:root -R ../pkg/craftware/usr
	chmod 755 -R ../pkg/craftware/usr
}

Thanks in advance!

Last edited by kalsan (2017-07-29 20:07:51)

ooo · 2017-07-29 09:18:54

kalsan wrote:

-> All the opt files are "outside of a valid path" but appearently the .deb wants to use the /opt folder. How should I react?

/opt is the correct install location for large self-containing packages, which usually means pre-build binary packages: https://wiki.archlinux.org/index.php/Ar … irectories

-> It sais that EULA is not a valid license, but I can't find a proprietary license in /usr/share/licenses/common/

EULA is not a specific license. See https://wiki.archlinux.org/index.php/PKGBUILD#license

-> This is 32bit software and it will very likely depend on multilib. How should I indicate that in the PKGBUILD?

Take a look at the PKGBUILD of any 32bit only binary package (steam is the only thing that comes to mind right now), and take a look how it handles dependencies.

-> Right now I'm dealing with permissions in the package() but I need to reference the parent folder to use chmod or chown. Is this the proper way to do it?

~~I don't think there should ever be any reason to use chown in PKGBUILD. File ownership won't be saved in the package anyway. Using chmod may be necessary on some cases though.~~

Nevertheless, if I understood your question correctly, in this case you could use e.g. ~~"${pkgdir}"/craftware/opt/~~ "${pkgdir}"/opt/. Although I don't think there's anything wrong with way you've dealt with it anyway.

Last edited by ooo (2017-07-29 10:12:34)

kalsan · 2017-07-29 09:25:37

Thanks for your reply! There's one thing that isn't clear, it's about the file ownership: If I don't do it, namcap yells at me, so there's gotta be a reason?

Btw steam is an official package now and cannot be found on the AUR, but skype has the requested form too: https://aur.archlinux.org/cgit/aur.git/ … LD?h=skype

Last edited by kalsan (2017-07-29 09:29:18)

ooo · 2017-07-29 10:11:26

Okay, sorry I didn't think the permission thing trough. Of course there are cases when you have to set file ownership, but I'm still not sure how makepkg/pacman handles those.

According to namcap wiki page you should use root:root for binary packages.

There was another error in my previous post. $pkgdir points to build_dir/pkg/$pkgname/, so you would use e.g. "${pkgdir}"/opt/ instead of "${pkgdir}"/craftware/opt/.

Sorry about all the confusion.

You can also view PKGBUILDs for official packages. They are all on git repo, that can be viewed online. Just pick any package from archlinux.org/packages, and select "Source files" from "Package actions" in upper right corner.

For example steam PKGBUILD is here: https://git.archlinux.org/svntogit/comm … ages/steam. It uses depends_x86_64= which seems nicer to me than the CARCH checks in the skype PKGBUILD

Lone_Wolf · 2017-07-29 13:41:24

As this is proprietary software, https://wiki.archlinux.org/index.php/No … guidelines should be helpful.

Many -bin packages in AUR use .deb files , check f.e. cndrvcups-lb-bin .

kalsan · 2017-07-29 20:07:37

Learned a lot today from you folks, thank you :-)

Turns out craftware seems to be completely broken under Linux (it seems to work fine but the slicing process just produces a craaazy mess). So for future readers of this post: I'm not sure I would be able to publish this in the AUR due to the craftware bugs.

I'll close this since my questions have been answered. I'll do further tests and, if successful, publish the package. Otherwise it was just a nice learning session. Thanks for the answers!

eschwartz · 2017-07-30 13:45:18

kalsan wrote:

Thanks for your reply! There's one thing that isn't clear, it's about the file ownership: If I don't do it, namcap yells at me, so there's gotta be a reason?

FWIW, not really. namcap is an automated linter which tries to find common mistakes, and often has false positives, or misses something it should warn about. That's just the nature of automated linters.

In this case, it is rightfully wondering what's with the weird /opt filepath, but discounting the fact that for very nonstandard things like precompiled binaries, /opt makes sense.

Maybe namcap should consider that a valid filepath, but then people won't be alerted to the fact that that is a non-optimal way to do things -- and then people who aren't repackaging precompiled binaries will, in fact, try to stuff things there that shouldn't go there.
Maybe namcap should get a more elaborate warning for this specific case.
Maybe namcap is just a terrible kludge and it's just not worth fixing it, because "everyone" already knows what that warning really means.

tl;dr Consider namcap as something useful to alert you to possible trouble areas, but take everything it says with a grain of salt and don't be afraid to tell namcap that it is wrong.

...

Note also that 32-bit software will probably end up needing depends_i686=('a' 'bunch' 'of' 'packages') and depends_x86_64=('lib32-a' 'lib32-bunch' 'lib32-of' 'lib32-packages') in order to work on both i686 and x86_64.

@ooo,
makepkg will of course `tar` up the "$pkgdir" with file permissions and all. But they get extracted using their numeric ID. And most things should be owned by root, with exceptions that are very specifically exceptions. The wiki has https://wiki.archlinux.org/index.php/De … D_Database to track the numeric IDs of things in the official repos. Common, obvious examples are logfiles, cron, mail applications, and HTTP servers.

severach · 2017-07-30 18:58:11

Adding lib32- to the dependencies is easy with bash. This ensures you don't miss any from one to the other.

depends_x86_64=("${depends_i686[@]/#/lib32-}")

kalsan · 2017-08-04 13:58:24

Thanks! :-)

helix · 2017-08-07 16:38:11

You can also try debtap from AUR with these parameters

debtap -swP file.deb

kalsan · 2017-08-08 09:49:34

Nice tool! Unfortunately it also has the problems with the permissions and missing dependencies.

Arch Linux

#1 2017-07-29 08:40:14

[solved] PKGBUILD for .deb

#2 2017-07-29 09:18:54

Re: [solved] PKGBUILD for .deb

#3 2017-07-29 09:25:37

Re: [solved] PKGBUILD for .deb

#4 2017-07-29 10:11:26

Re: [solved] PKGBUILD for .deb

#5 2017-07-29 13:41:24

Re: [solved] PKGBUILD for .deb

#6 2017-07-29 20:07:37

Re: [solved] PKGBUILD for .deb

#7 2017-07-30 13:45:18

Re: [solved] PKGBUILD for .deb

#8 2017-07-30 18:58:11

Re: [solved] PKGBUILD for .deb

#9 2017-08-04 13:58:24

Re: [solved] PKGBUILD for .deb

#10 2017-08-07 16:38:11

Re: [solved] PKGBUILD for .deb

#11 2017-08-08 09:49:34

Re: [solved] PKGBUILD for .deb

Board footer