Creating integrated packages

blippy · 2015-12-16 11:04:07

I want to create a fortran library, and package it for Arch. Since I am the author, I can create a repo containing both the source and package info. There is no need for a separate download phase.

Is it possible to do this?

Lone_Wolf · 2015-12-16 11:40:51

possible : yes
A good idea : i doubt it

makepkg expects a certain structure.
You could replicate that structure in your repo, and include installation instructions on a wiki page.
Main problem with that approach is that a package with sourcecode included is very unlikely to be accepted in the AUR.
MAYBE if would be accepted if the sourcecode is 1 or 2 small files.

Not being in the AUR may result in users having trouble finding your library.

Is there a specific reason why you don't want a separate download phase ?

blippy · 2015-12-16 17:31:32

Well, the reason I want to put it in one is for convenience. Why download a tar file when I have the source code right there? Most packagers have to do it this way because upstream doesn't do the Arch packaging for them. But I am my own "upstream" in this particular case, so downloading sources seems a roundabout way of doing things.

I do still like the idea of packaging of my repo, though, as it is then under proper package management control.

Lone_Wolf · 2015-12-17 10:23:44

Thanks for clarifying.
While using tarballs is common,makepkg supports much more protocols to get sourcecode.

man PKGBUILD , USING VCS SOURCES has details.
If you use git and have a tag "release-0.1" you could use this in the PKGBUILD :
source=('project_name::git+http://project_url#tag=release-0.1')

makepkg will "git clone" to download your sourcecode.

AUR uses git now also and there are ways to link the aur repo for your package to your own git repo that holds PKGBUILD and other files needed for makepkg.

Trilby · 2015-12-17 15:04:23

blippy wrote:

Most packagers have to do it this way because upstream doesn't do the Arch packaging for them.

While I wouldn't disagree with the "most" here, I would emphasize that "most" is no where near "all". Your situation is not remotely unique.

You can have the PKGBUILD in the same VCS repo as the source, this is not issue. But you only post the PKGBUILD (which pulls from that VCS) to the AUR. You cannot post the source to the AUR, it will be deleted.

See one example here:
https://github.com/TrilbyWhite/interrobang

blippy · 2015-12-17 16:39:55

Trilby wrote:

But you only post the PKGBUILD (which pulls from that VCS) to the AUR.
See one example here:
https://github.com/TrilbyWhite/interrobang

Interesting. Thanks.

Followup question: so the interrobang package is always built against the latest commit. Isn't that dangerous (from an integrity viewpoint, rather than a security one)? The sources for my pkgver=0.41.467978d pkgrel=1 might be different from your pkgver=0.41.467978d pkgrel=1.

Scimmia · 2015-12-17 16:59:02

blippy, how would the sources be different?

blippy · 2015-12-17 17:21:07

Scimmia wrote:

blippy, how would the sources be different?

Because a git's HEAD is a moving target. My argument is that if I give you a package name, a pkgver and a pkgrel, then you should be able to tell me, definitively, what the source tree is for that trio. If your answer is "it's whatever is at HEAD", then the build tree isn't tied down.

We don't know, for example, that the latest commit is meant for release.

I guess the way to achieve robustness is for the author to decide to make a release, update the pkgver with a new release number, specify the source with a tag version, commit the changes, tag the commit and push the tag. That way you can always say what code went into what package-version-rel.

Scimmia · 2015-12-17 17:23:13

But you didn't look at what those number represent.

blippy · 2015-12-17 18:08:35

Scimmia wrote:

But you didn't look at what those number represent.

I initially assumed that pkgver=0.41.467978d was a reference to a commit 467978d, but I couldn't spot it at
https://github.com/TrilbyWhite/interrobang

I dug into it, and discovered that it is, indeed a commit:
git checkout 467978d

I guess that kinda makes sense. I'm beginning to understand Arch packaging a little better.

Trilby · 2015-12-17 18:26:37

blippy wrote:

I guess the way to achieve robustness is for the author to decide to make a release, update the pkgver with a new release number, specify the source with a tag version, commit the changes, tag the commit and push the tag. That way you can always say what code went into what package-version-rel.

You certainly can do that. You will find other examples out there were people do this - I didn't with interrobang.

blippy wrote:

I dug into it, and discovered that it is, indeed a commit:
git checkout 467978d

But that commit/version number is irrelevant: whenever makepkg is run on a VCS PKGBUILD the pkgver function will update the package version. If you use the PKGBUILD provided you will (at this moment) get version 0.136.6f50db7-1.

Again, the main point of my posts has not been that the specific choices I made for interrobang will be the same choices you will want to make (actually looking back at it I should touch up a few things). The point is that your situation is not even remotely a novel one. Please look into the documentation (wiki, man pages) and look at what other packages do in the AUR.

Arch Linux

#1 2015-12-16 11:04:07

Creating integrated packages

#2 2015-12-16 11:40:51

Re: Creating integrated packages

#3 2015-12-16 17:31:32

Re: Creating integrated packages

#4 2015-12-17 10:23:44

Re: Creating integrated packages

#5 2015-12-17 15:04:23

Re: Creating integrated packages

#6 2015-12-17 16:39:55

Re: Creating integrated packages

#7 2015-12-17 16:59:02

Re: Creating integrated packages

#8 2015-12-17 17:21:07

Re: Creating integrated packages

#9 2015-12-17 17:23:13

Re: Creating integrated packages

#10 2015-12-17 18:08:35

Re: Creating integrated packages

#11 2015-12-17 18:26:37

Re: Creating integrated packages

Board footer