[Policy Request] Seperate PKGBUILDs for different packages

G3ro · 2020-10-20 16:21:04

As the PKGBUILDs in AUR are used to compile & install packages, it would be useful to tell maintainers that they should split PKGBUILDs that do not necessarily need to be put together.

One example is anbox-git, which includes both "anbox-git" and "anbox-modules-dkms-git".
The second package is not necessary and not supported on newer kernels anymore.

So it would be convenient to split the PKGBUILD into two packages instead.

shulamy · 2020-10-20 18:05:06

i see tow packages

and are you sure it's not necessary ?

ezik

G3ro · 2020-10-20 19:56:55

@shulamy:

1. Yes there are two packages, but from one PKGBUILD only, which is the point.

2. Yes I am sure, that it is not necessary anymore, because it does not work anymore. You can read about that on the Anbox wiki page.
But the point is not this package alone, it is the concept of putting two or more packages in one PKGBUILD, which is not convenient (in/for all cases).

progandy · 2020-10-20 20:00:23

There is an implicit understanding that a split package is used if the same sources build two or more different packages. Adding two different sources in the same package and then split them again later is bad practice. I don't know of any written guidelines about that, though.

G3ro · 2020-10-20 20:37:45

progandy wrote:

There is an implicit understanding that a split package is used if the same sources build two or more different packages. Adding two different sources in the same package and then split them again later is bad practice. I don't know of any written guidelines about that, though.

Update: Sry misunderstood your post .

Last edited by G3ro (2020-10-21 18:06:22)

Trilby · 2020-10-20 21:05:38

I don't see how progandy is supporting your proposal, he explained the criteria for split packages (one PKGBUILD that makes more than one package). The example you provided meets the criteria, and by that logic should be a single PKGBUILD.

If one of the resulting packages is faulty and / or no longer necessary, that is a different issue.

G3ro · 2020-10-21 18:37:12

Trilby wrote:

I don't see how progandy is supporting your proposal, he explained the criteria for split packages (one PKGBUILD that makes more than one package).

Ok, deleted my comment about that.

Trilby wrote:

The example you provided meets the criteria, and by that logic should be a single PKGBUILD.

I would like that to be added to the guidelines (couldn't find it, but maybe I oversaw it).
Whom should I talk to about it?
Should I post it in the Wiki Discussion?

Trilby wrote:

If one of the resulting packages is faulty and / or no longer necessary, that is a different issue.

Well it can still be used on linux-lts, so some people would like to keep it.
I already wrote to the maintainer, we will see if and when they respond.

Trilby · 2020-10-21 19:39:59

As noted above - there likely isn't any specific documentation for if / when a package should be split. The criteria are not precise, but rather there are just some historical guidelines (much just from common sense).

First recognize that singular packages were the predecessor to split packages (hence the name); this is in contrast to there being multiple packages that get merged together (which would have been called merged packages, or franken-packages ...)

When there is one (set of) source(s) and one build process, there only needs to be one PKGBUILD. Having a second one would be redundant. And initially this would have produced one package. But in some cases, it was determined that singular upstream sources built several optional bits that many users may not want - and they may be cumbersome.

The traditional examples are packages for which upstream provides both a gtk and qt frontend UI - or a python2 and python3 version. A single upstream source creates all of these options, but most users would only want to install one or the other. So the gtk and qt content of a single package is split into two packages.

So the question has never been "should this be a split package or two seperate packages?" but only "should this be a split package or a unified package?" This later question is where the criteria are a bit subjective, but the former question really doesn't need to be asked.

G3ro · 2020-10-25 20:33:09

I guess I will simply ask in the wiki.

eschwartz · 2020-10-25 21:39:29

I find myself completely confused by https://aur.archlinux.org/cgit/aur.git/ … =anbox-git

There are 4 source downloads.

#1 is used for pkgver(), build(), and package_anbox-git()

#3 and #4 are submodules of #1

#2 is used for nothing other than package_anbox-modules-dkms-git(), which is an optdepends of the first split package.

So, it is literally one package randomly included inside another, does not share source code or build processes, and loses its ability to have a unique $pkgver

...

Trilby, I don't understand your comment "The example you provided meets the criteria, and by that logic should be a single PKGBUILD." Am I completely missing something?

I don't see a single reason to use one PKGBUILD, it seems to be a clear-cut policy violation.

G3ro · 2020-10-25 22:13:15

eschwartz wrote:

I find myself completely confused by https://aur.archlinux.org/cgit/aur.git/ … =anbox-git
There are 4 source downloads.
#1 is used for pkgver(), build(), and package_anbox-git()
#3 and #4 are submodules of #1
#2 is used for nothing other than package_anbox-modules-dkms-git(), which is an optdepends of the first split package.
So, it is literally one package randomly included inside another, does not share source code or build processes, and loses its ability to have a unique $pkgver
...
Trilby, I don't understand your comment "The example you provided meets the criteria, and by that logic should be a single PKGBUILD." Am I completely missing something?
I don't see a single reason to use one PKGBUILD, it seems to be a clear-cut policy violation.

Thank you very much.
I misunderstood the former comments, I thought they understood the problem and agreed for it to be at least bad practice; seems now I was wrong about that.

My request is to explain exactly that in the Package Guidelines of the wiki: when one can/or should use one PKGBUILD and when to use seperate PKGBUILDs.
Because I could not find such a policy.

Regarding anbox-git: it seems the maintainer never answers any comments on AUR, so maybe after waiting some more time, other steps could be taken?

Trilby · 2020-10-25 22:23:04

eschwartz wrote:

Trilby, I don't understand your comment "The example you provided meets the criteria, and by that logic should be a single PKGBUILD." Am I completely missing something?

I based my assessment on the single build process - only one unified call to make. There is no distinct build processes that could be split. The fact that submodules are used to build in additional features doesn't change this.

If the dkms part doesn't even need to be built then this perhaps should be seperate.

eschwartz · 2020-10-25 22:36:08

Aha, so you simply overlooked that the dkms module wasn't even being built in build(). Makes sense.

I guess we're all in agreement, then. This should get a new PKGBUILD just for package_anbox-modules-dkms-git().

Arch Linux

#1 2020-10-20 16:21:04

[Policy Request] Seperate PKGBUILDs for different packages

#2 2020-10-20 18:05:06

Re: [Policy Request] Seperate PKGBUILDs for different packages

#3 2020-10-20 19:56:55

Re: [Policy Request] Seperate PKGBUILDs for different packages

#4 2020-10-20 20:00:23

Re: [Policy Request] Seperate PKGBUILDs for different packages

#5 2020-10-20 20:37:45

Re: [Policy Request] Seperate PKGBUILDs for different packages

#6 2020-10-20 21:05:38

Re: [Policy Request] Seperate PKGBUILDs for different packages

#7 2020-10-21 18:37:12

Re: [Policy Request] Seperate PKGBUILDs for different packages

#8 2020-10-21 19:39:59

Re: [Policy Request] Seperate PKGBUILDs for different packages

#9 2020-10-25 20:33:09

Re: [Policy Request] Seperate PKGBUILDs for different packages

#10 2020-10-25 21:39:29

Re: [Policy Request] Seperate PKGBUILDs for different packages

#11 2020-10-25 22:13:15

Re: [Policy Request] Seperate PKGBUILDs for different packages

#12 2020-10-25 22:23:04

Re: [Policy Request] Seperate PKGBUILDs for different packages

#13 2020-10-25 22:36:08

Re: [Policy Request] Seperate PKGBUILDs for different packages

Board footer