PKGBUILD version constrained implementation

noEntry · 2016-09-11 10:40:22

Hello,

can someone tell me how the version constraint stuff in the dependency array actually work?
I am currently trying to build a script that builds an AUR package and all its dependencies, thus
I can add the resulting packages into my own repo.

For example seafile-shared has the dependency ccnet=5.0.2, but there is only ccnet 6.0.0-1 in the AUR.
How can I satisfy the dependency, so that seafile-shared is not complaining because ccnet=6.0.0-1
is not installed?

==> Making package: seafile-shared 5.0.2-1 (Sun Sep 11 10:22:38 UTC 2016)
==> Checking runtime dependencies...
==> Installing missing dependencies...
error: target not found: ccnet=5.0.2

Do I need to checkout a specific commit after pulling ccnet?

Also I have noticed that if I install
seafile-shared with packer, packer just installs ccnet=6.0.0-1, but when seafile-shared is installed it
isn't complaining about missing dependencies.

Thanks in advance

Last edited by noEntry (2016-09-11 10:41:03)

Awebb · 2016-09-11 10:51:31

You're working with an old PKGBUILD of seafile-shared.

We have

pkgver=6.0.0

and

makedepends=( ... "ccnet>=${pkgver}" ... )

therefore packer does what it should.

GordonGR · 2016-09-11 10:53:22

noEntry wrote:

For example seafile-shared has the dependency ccnet=5.0.2, but there is only ccnet 6.0.0-1 in the AUR. How can I satisfy the dependency, so that seafile-shared is not complaining because ccnet=6.0.0-1 is not installed?

I think this “=” thing is the source of all evil in AUR… It disturbs upgrades, but people still use it! I don't know the programs you mention, but I will tell you what I would do:
(a) If seafile-shared does not need specifically ccnet 5.0.2 but any version greater or equal to that, I would put “ccnet>=5.02” as the dependency.
(b) If it needs specifically 5.0.2, then I would make a ccnet502 package, that builds 5.0.2 and will do so for the rest of time (until it no longer can be built, that is) that would conflict to and provide ccnet, and add this as a dependency to seafile-shared.

noEntry · 2016-09-11 11:05:24

GordonGR wrote:

noEntry wrote:
For example seafile-shared has the dependency ccnet=5.0.2, but there is only ccnet 6.0.0-1 in the AUR. How can I satisfy the dependency, so that seafile-shared is not complaining because ccnet=6.0.0-1 is not installed?
I think this “=” thing is the source of all evil in AUR… It disturbs upgrades, but people still use it! I don't know the programs you mention, but I will tell you what I would do:
(a) If seafile-shared does not need specifically ccnet 5.0.2 but any version greater or equal to that, I would put “ccnet>=5.02” as the dependency.
(b) If it needs specifically 5.0.2, then I would make a ccnet502 package, that builds 5.0.2 and will do so for the rest of time (until it no longer can be built, that is) that would conflict to and provide ccnet, and add this as a dependency to seafile-shared.

So there is not really any beautiful way for fulfilling fixed (=) dependency constraints?

Awebb wrote:

You're working with an old PKGBUILD of seafile-shared.
We have
pkgver=6.0.0
and
makedepends=( ... "ccnet>=${pkgver}" ... )
therefore packer does what it should.

Could you tell me then, how I get programmatically the latest PKGBUILDs?
Interestingly git clone https://aur.archlinux.org/seafile-shared.git delivers the following PKGBUILD:

...
pkgname=seafile-shared
pkgver=5.0.2
pkgrel=1
pkgdesc="Shared components of seafile: seafile-daemon, libseafile, libseafile python bindings, manuals"
arch=('i686' 'x86_64' 'armv6h' 'armv7h')
url="https://github.com/haiwen/seafile/"
license=('GPL3')
depends=('ccnet=5.0.2' 'hicolor-icon-theme' 'gtk-update-icon-cache' 'fuse')

...

eschwartz · 2016-09-11 14:59:54

First you check the AUR (possibly via the RPC json interface) to determine the proper clone url, then you stop using the pre-merge-into-"seafile"-pkgbase clone url, then you take a look at the right PKGBUILD and notice how it, shockingly, isn't the same one you are erroneously looking at.

...

Also, @GordonGR, if a package depends on a specific version of another package, there is absolutely nothing wrong with saying so.

The fact that you may need to build in a clean chroot or else uninstall the old version of the package in order to build and install a newer version of a dependency, is not a problem with the AUR, it is a problem with the common workflow of people who use the AUR, and your solution of convenience results in a fundamental error in the built packages.

If people are adding versioned dependencies where there is NO good reason to, that is a separate problem.

Last edited by eschwartz (2016-09-11 15:04:44)

GordonGR · 2016-09-12 11:49:36

Eschwartz, the problem I am referring to is with lib32- packages in the AUR. There is a dogma saying: “If extra/foo is in version x, then lib32-foo must depend on foo=x.” Which breaks updates all the bloody time. And no, there is no reason for that dogma, unless I was out of town when the almighty dropped another stone writing it… Thankfully, many lib32- packages were moved to [multilib] recently, so this nonsense has lessened up And, needless to say, I edit the PKGBUILDs and remove the versioned dependency whenever I update. However, this is not the original poster's issue, so I'm stopping here.

Awebb · 2016-09-12 12:01:00

Eschwartz wrote:

First you check the AUR (possibly via the RPC json interface) to determine the proper clone url, then you stop using the pre-merge-into-"seafile"-pkgbase clone url, then you take a look at the right PKGBUILD and notice how it, shockingly, isn't the same one you are erroneously looking at.

What Eschwartz was trying to tell you, is that there is a split package involved and you assumed the wrong git path.

@GordonGR: No. That's not the problem here, the problem is an edge case, where an old package was merged into a split package. This won't happen to noEntry again, because now he knows about split packages on the AUR.

eschwartz · 2016-09-12 18:36:33

GordonGR wrote:

Eschwartz, the problem I am referring to is with lib32- packages in the AUR. There is a dogma saying: “If extra/foo is in version x, then lib32-foo must depend on foo=x.” Which breaks updates all the bloody time. And no, there is no reason for that dogma, unless I was out of town when the almighty dropped another stone writing it… Thankfully, many lib32- packages were moved to [multilib] recently, so this nonsense has lessened up And, needless to say, I edit the PKGBUILDs and remove the versioned dependency whenever I update. However, this is not the original poster's issue, so I'm stopping here.

In the context of lib32-* packages, your previous post makes absolutely no sense. However, you are certainly correct in saying that it has nothing to do with the OP's issue... so I am merely left wondering what compelled you to mention it in the first place.

Awebb · 2016-09-12 21:37:07

Eschwartz wrote:

... so I am merely left wondering what compelled you to mention it in the first place.

I am rather thrilled, that the SNR is so low on these forums, that you find the occasional "while we're at the topic of..." deviation puzzling.

Arch Linux

#1 2016-09-11 10:40:22

PKGBUILD version constrained implementation

#2 2016-09-11 10:51:31

Re: PKGBUILD version constrained implementation

#3 2016-09-11 10:53:22

Re: PKGBUILD version constrained implementation

#4 2016-09-11 11:05:24

Re: PKGBUILD version constrained implementation

#5 2016-09-11 14:59:54

Re: PKGBUILD version constrained implementation

#6 2016-09-12 11:49:36

Re: PKGBUILD version constrained implementation

#7 2016-09-12 12:01:00

Re: PKGBUILD version constrained implementation

#8 2016-09-12 18:36:33

Re: PKGBUILD version constrained implementation

#9 2016-09-12 21:37:07

Re: PKGBUILD version constrained implementation

Board footer