[aur-general] Split packages
Hi all, Christoph Gysin came up with the problem of split packages that conflict each other, which is implementable in a PKGBUILD. As an example consider https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pasystray which defines pasystray and pasystray-gtk2 which cannot be installed both at the same time. Neither aura nor yaourt supports such packages. There is no other package known to me, but there should be some clarification, whether such a package is allowed. In my opinion, already the name "split package" indicates that these should not conflict, otherwise it would not just be a split package, but rather something like a "versioned package". In order to come to a conclusion for the discussion in the comments of that AUR package, I would kindly ask you for your thoughts concerning this problem. Best, Lukas
Le 22 août 2016 12:53:04 GMT+02:00, Lukas Mosimann <mlukas@ethz.ch> a écrit :
Hi all,
Christoph Gysin came up with the problem of split packages that conflict each other, which is implementable in a PKGBUILD.
As an example consider https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pasystray which defines pasystray and pasystray-gtk2 which cannot be installed both at the same time. Neither aura nor yaourt supports such packages.
There is no other package known to me, but there should be some clarification, whether such a package is allowed.
In my opinion, already the name "split package" indicates that these should not conflict, otherwise it would not just be a split package, but rather something like a "versioned package".
In order to come to a conclusion for the discussion in the comments of that AUR package, I would kindly ask you for your thoughts concerning this problem.
Best, Lukas
AFAIR, the intent of split packages is to avoid downloading the source/building multiple times when possible in case you want to install part or all of the corresponding packages. Thus, I think there is no point in conflicting split packages, and regarding your example, that should then be two different packages. Regards, Bruno
On Mon, Aug 22, 2016 at 01:14:14PM +0200, Bruno Pagani wrote:
Le 22 août 2016 12:53:04 GMT+02:00, Lukas Mosimann <mlukas@ethz.ch> a écrit :
Hi all,
Christoph Gysin came up with the problem of split packages that conflict each other, which is implementable in a PKGBUILD.
As an example consider https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pasystray which defines pasystray and pasystray-gtk2 which cannot be installed both at the same time. Neither aura nor yaourt supports such packages.
There is no other package known to me, but there should be some clarification, whether such a package is allowed.
In my opinion, already the name "split package" indicates that these should not conflict, otherwise it would not just be a split package, but rather something like a "versioned package".
In order to come to a conclusion for the discussion in the comments of that AUR package, I would kindly ask you for your thoughts concerning this problem.
Best, Lukas
AFAIR, the intent of split packages is to avoid downloading the source/building multiple times when possible in case you want to install part or all of the corresponding packages.
Thus, I think there is no point in conflicting split packages, and regarding your example, that should then be two different packages.
But then you will have two PKGBUILDs that only differ by few lines within the build() function, and two separate repositories to support them. They are not two different packages, they are the same package but compiled differently. I think it makes sence to have one PKGBUILD that can procude different packages, and they have to conflict with each other to make sure someone does not install both at the same time. If tools cannot handle it then tools should be modified to allow for this workflow. just my two cents. Misha -- Vanush "Misha" Paturyan Senior Technical Officer Room 120 Computer Science Department Eolas Bulding Maynooth University Maynooth ext: 4539
On Mon, Aug 22, 2016 at 9:54 PM, Vanush Misha Paturyan via aur-general < aur-general@archlinux.org> wrote:
On Mon, Aug 22, 2016 at 01:14:14PM +0200, Bruno Pagani wrote:
Le 22 août 2016 12:53:04 GMT+02:00, Lukas Mosimann <mlukas@ethz.ch> a
écrit :
Hi all,
Christoph Gysin came up with the problem of split packages that conflict each other, which is implementable in a PKGBUILD.
As an example consider https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pasystray which defines pasystray and pasystray-gtk2 which cannot be installed both at the same time. Neither aura nor yaourt supports such packages.
There is no other package known to me, but there should be some clarification, whether such a package is allowed.
In my opinion, already the name "split package" indicates that these should not conflict, otherwise it would not just be a split package, but rather something like a "versioned package".
In order to come to a conclusion for the discussion in the comments of that AUR package, I would kindly ask you for your thoughts concerning this problem.
Best, Lukas
AFAIR, the intent of split packages is to avoid downloading the source/building multiple times when possible in case you want to install part or all of the corresponding packages.
Thus, I think there is no point in conflicting split packages, and regarding your example, that should then be two different packages.
But then you will have two PKGBUILDs that only differ by few lines within the build() function, and two separate repositories to support them. They are not two different packages, they are the same package but compiled differently. I think it makes sence to have one PKGBUILD that can procude different packages, and they have to conflict with each other to make sure someone does not install both at the same time. If tools cannot handle it then tools should be modified to allow for this workflow.
just my two cents.
Misha
-- Vanush "Misha" Paturyan Senior Technical Officer Room 120 Computer Science Department Eolas Bulding Maynooth University Maynooth
ext: 4539
FWIW, I have a Python script [1] that generates multiple PKGBUILDs from a template file PKGBUILD.template and a parameter file pkgs.json. I wrote this script to manage Python packages targetting different Python versions. (for example python2-xxx and python-xxx) It may be helpful in such cases, too. [1] https://github.com/yan12125/aur/blob/master/scripts/generate_packages_from_t...
On 08/22/2016 04:02 PM, Chi Hsuan Yen via aur-general wrote:
FWIW, I have a Python script [1] that generates multiple PKGBUILDs from a template file PKGBUILD.template and a parameter file pkgs.json. I wrote this script to manage Python packages targetting different Python versions. (for example python2-xxx and python-xxx) It may be helpful in such cases, too.
That pretty much defeats the whole purpose of split packages. If there is something like "the one showpiece" then it is to unify python2- and python- variants into a single PKGBUILD. I honestly recommend you get a bit familiar with split packages and unify all your separated python packages into a single PKGBUILD. cheers, Levente
On Tue, Aug 23, 2016 at 7:32 PM, Levente Polyak <anthraxx@archlinux.org> wrote:
On 08/22/2016 04:02 PM, Chi Hsuan Yen via aur-general wrote:
FWIW, I have a Python script [1] that generates multiple PKGBUILDs from a template file PKGBUILD.template and a parameter file pkgs.json. I wrote this script to manage Python packages targetting different Python versions. (for example python2-xxx and python-xxx) It may be helpful in such cases, too.
That pretty much defeats the whole purpose of split packages. If there is something like "the one showpiece" then it is to unify python2- and python- variants into a single PKGBUILD. I honestly recommend you get a bit familiar with split packages and unify all your separated python packages into a single PKGBUILD.
cheers, Levente
At first I used split packages for python-* packages in my AUR repo. However, since pacman commit e8deba3b87784ca14c9afc908046f36a3ad7578c, [1][2] there's no way to build a subset of split packages. That is, people who use Python 3 (or Python 2) only need to install both Python versions to build my package. It would be nice if I can use a single PKGBUILD and build only a subset of split packages with makepkg. Best, Yen Chi Hsuan [1] https://git.archlinux.org/pacman.git/commit/?id= e8deba3b87784ca14c9afc908046f36a3ad7578c [2] https://lists.archlinux.org/pipermail/pacman-dev/2015- September/020347.html
On 08/23/2016 09:11 AM, Chi Hsuan Yen via aur-general wrote:
At first I used split packages for python-* packages in my AUR repo. However, since pacman commit e8deba3b87784ca14c9afc908046f36a3ad7578c, [1][2] there's no way to build a subset of split packages. That is, people who use Python 3 (or Python 2) only need to install both Python versions to build my package. It would be nice if I can use a single PKGBUILD and build only a subset of split packages with makepkg.
That is a confusing statement... Before that pacman commit, you still had to install python2 and python3 makedepends, and run the unified build function. The only thing that commit changed is that now you also have to run both package_* functions and create the package tarball. So if you truly had an issue with requiring all those makedepends, that should always have been a problem, and you shouldn't be using this^^ as an excuse. -- Eli Schwartz
On Tue, Aug 23, 2016 at 10:10 PM, Eli Schwartz via aur-general < aur-general@archlinux.org> wrote:
At first I used split packages for python-* packages in my AUR repo. However, since pacman commit e8deba3b87784ca14c9afc908046f36a3ad7578c, [1][2] there's no way to build a subset of split packages. That is,
On 08/23/2016 09:11 AM, Chi Hsuan Yen via aur-general wrote: people
who use Python 3 (or Python 2) only need to install both Python versions to build my package. It would be nice if I can use a single PKGBUILD and build only a subset of split packages with makepkg.
That is a confusing statement...
Before that pacman commit, you still had to install python2 and python3 makedepends, and run the unified build function.
The only thing that commit changed is that now you also have to run both package_* functions and create the package tarball.
So if you truly had an issue with requiring all those makedepends, that should always have been a problem, and you shouldn't be using this^^ as an excuse.
-- Eli Schwartz
Well the thread goes to something else since my post... Python packages are not good examples for this thread. I mention my script as I find it useful for handling such cases. As Bruno said, using two separate packages is the choice. My script just reduces the overhead of maintaining two separate PKGBUILDs.
On August 23, 2016 4:24:25 PM GMT+02:00, Chi Hsuan Yen via aur-general <aur-general@archlinux.org> wrote:
As Bruno said, using two separate packages is the choice. My script just reduces the overhead of maintaining two separate PKGBUILDs.
You mean the -gtk2 variant? No its not, read my previous post. That should be the very same PKGBUILD. Cheers, Levente
On 08/23/2016 10:24 AM, Chi Hsuan Yen wrote:
Python packages are not good examples for this thread.
Whyever not? It seems an excellent example to me...
I mention my script as I find it useful for handling such cases. As Bruno said, using two separate packages is the choice. My script just reduces the overhead of maintaining two separate PKGBUILDs.
I am not sure how that is supposed to answer my question. I am simply wondering why any of that has anything to do with your factually incorrect claim that you ended up (ab)using multiple PKGBUILDs *as a result of* makepkg dropping support for the "--pkg" flag. Because, once again, if you really thought it was important to save casual AUR users the horrifying burden of temporarily installing an extra makedepends... then they would have always had to, and you would have had a problem for a lot longer. Not that that is actually a valid excuse for using separate PKGBUILDs... but it just goes to show that even your own argument in favor, is severely flawed. -- Eli Schwartz
On Tue, 23 Aug 2016 10:43:25 -0400 Eli Schwartz via aur-general <aur-general@archlinux.org> wrote:
I am not sure how that is supposed to answer my question. I am simply wondering why any of that has anything to do with your factually incorrect claim that you ended up (ab)using multiple PKGBUILDs *as a result of* makepkg dropping support for the "--pkg" flag.
You call multiple PKGBUILDs abuse. I call copying the entire source and running two builds in a single PGKBUILD abuse. There is only one build function for a reason.
On 08/23/2016 04:57 PM, Doug Newgard wrote:
On Tue, 23 Aug 2016 10:43:25 -0400 Eli Schwartz via aur-general <aur-general@archlinux.org> wrote:
I am not sure how that is supposed to answer my question. I am simply wondering why any of that has anything to do with your factually incorrect claim that you ended up (ab)using multiple PKGBUILDs *as a result of* makepkg dropping support for the "--pkg" flag.
You call multiple PKGBUILDs abuse. I call copying the entire source and running two builds in a single PGKBUILD abuse. There is only one build function for a reason.
Its totally non-sense to bump N packages to the same version and build them one by one just because you have N variants from the very same source.
On Tue, 23 Aug 2016 17:09:05 +0200 Levente Polyak <anthraxx@archlinux.org> wrote:
On 08/23/2016 04:57 PM, Doug Newgard wrote:
On Tue, 23 Aug 2016 10:43:25 -0400 Eli Schwartz via aur-general <aur-general@archlinux.org> wrote:
I am not sure how that is supposed to answer my question. I am simply wondering why any of that has anything to do with your factually incorrect claim that you ended up (ab)using multiple PKGBUILDs *as a result of* makepkg dropping support for the "--pkg" flag.
You call multiple PKGBUILDs abuse. I call copying the entire source and running two builds in a single PGKBUILD abuse. There is only one build function for a reason.
Its totally non-sense to bump N packages to the same version and build them one by one just because you have N variants from the very same source.
PKGBUILDs are based around 1 build, not one source.
On 08/23/2016 10:57 AM, Doug Newgard wrote:
You call multiple PKGBUILDs abuse. I call copying the entire source and running two builds in a single PGKBUILD abuse. There is only one build function for a reason.
If you wish to make that claim, I am sure you can come up with a better reason than "there is only one build function for a reason". There is only one build function, because there is no reason to have multiple build functions. But there is a reason to have multiple package_* functions, because each package_* function defines the final contents of a split package. You already know this. ... FUD aside, the prevailing opinion by Developers, Trusted Users, and AUR contributors is against you. As Levente said, it is not very sensible to maintain and bump pkgvers for multiple PKGBUILDs, then download and build them all separately one by one. As a maintainer, it is a waste of effort, and as someone building both packages, it is a waste of effort.
PKGBUILDs are based around 1 build, not one source.
Says who? I'll say that PKGBUILDs are based around "one logically contiguous thing to desire to create"... Anyway, maybe we should build each component of a split PKGBUILD separately, as long as their Makefile defines separate sub-targets (which don't depend on each other). There are more than a couple of those... I think it is a problem to be overly-pedantic about what should define a PKGBUILD, rather than simply going with whatever, practically speaking, is advantageous. -- Eli Schwartz
On Tue, 23 Aug 2016 11:33:38 -0400 Eli Schwartz via aur-general <aur-general@archlinux.org> wrote:
PKGBUILDs are based around 1 build, not one source.
Says who? I'll say that PKGBUILDs are based around "one logically contiguous thing to desire to create"...
How about the Pacman/makepkg developers? https://bugs.archlinux.org/task/38160
You call multiple PKGBUILDs abuse. I call copying the entire source and running two builds in a single PGKBUILD abuse. There is only one build function for a reason. ...
FUD aside, the prevailing opinion by Developers, Trusted Users, and AUR contributors is against you. As Levente said, it is not very sensible to maintain and bump pkgvers for multiple PKGBUILDs, then download and build them all separately one by one.
As a maintainer, it is a waste of effort, and as someone building both packages, it is a waste of effort.
So the minority opinion is automatically wrong now? The devs I've talked to will admit it's a hack, it just doesn't matter much in the repos so they think it's worth it. The AUR is different. I was just going to let this topic go until you started going after someone who was doing things right, even though it's slightly more work for them.
On 08/23/2016 11:59 AM, Doug Newgard wrote:
How about the Pacman/makepkg developers? https://bugs.archlinux.org/task/38160
I was unaware of that bugreport. But having read it, it seems to me that the problem there is when you cannot have a package both installed and uninstalled, and the two versions of the package have no way of specifying to NOT use a feature that has the necessary makedepends installed. Which means the feature request was more like asking for Gentoo USE flags. And that package would have trouble anyway, if you try to build the -nox package outside a clean chroot. Even the requested solution wouldn't have actually solved anything...
So the minority opinion is automatically wrong now? The devs I've talked to will admit it's a hack, it just doesn't matter much in the repos so they think it's worth it. The AUR is different. I was just going to let this topic go until you started going after someone who was doing things right, even though it's slightly more work for them.
The minority opinion is not automatically wrong. But it may be wrong, and in my opinion, in this case it *is* wrong. However, I haven't really talked to people about it, I am basing my opinions just off what I've seen... so maybe it is a hack the devs don't like but have no better solution for, I wouldn't know. :o Though if there isn't a better solution available, I would say that still makes it something you should do. ;) -- Eli Schwartz
On Tue, Aug 23, 2016 at 10:43 PM, Eli Schwartz via aur-general < aur-general@archlinux.org> wrote:
On 08/23/2016 10:24 AM, Chi Hsuan Yen wrote:
Python packages are not good examples for this thread.
Whyever not? It seems an excellent example to me...
All Python build commands can be put into package(), while GTK applications not. It doesn't make a difference with current pacman and makepkg, though.
I mention my script as I find it useful for handling such cases. As Bruno said, using two separate packages is the choice. My script just reduces the overhead of maintaining two separate PKGBUILDs.
I am not sure how that is supposed to answer my question. I am simply wondering why any of that has anything to do with your factually incorrect claim that you ended up (ab)using multiple PKGBUILDs *as a result of* makepkg dropping support for the "--pkg" flag.
Because, once again, if you really thought it was important to save casual AUR users the horrifying burden of temporarily installing an extra makedepends... then they would have always had to, and you would have had a problem for a lot longer.
Not that that is actually a valid excuse for using separate PKGBUILDs... but it just goes to show that even your own argument in favor, is severely flawed.
-- Eli Schwartz
On 08/23/2016 11:27 AM, Chi Hsuan Yen via aur-general wrote:
All Python build commands can be put into package(), while GTK applications not. It doesn't make a difference with current pacman and makepkg, though.
You can put whatever commands you want in package(), gtk or otherwise. Which I think is exactly what you are doing in regards to python. The package() function is meant to separate the final step of copying over files into the pkg/ tree independent of everything else, ideally src/ should be treated as close to readonly as possible during package(). During the installation of a python package, it figures out the list of modules defined in setup.py and copies them into the right hierarchy in build/ as well as compiling any potential binary components. Then it copies the contents of the build/ hierarchy (whatever that may be, irrespective of the original source code) into the installation root. Just because it is copying files around rather than running them through a C compiler, that makes it less of a build() sort of thing??? -- Eli Schwartz
On Tue, Aug 23, 2016 at 11:41 PM, Eli Schwartz via aur-general < aur-general@archlinux.org> wrote:
All Python build commands can be put into package(), while GTK applications not. It doesn't make a difference with current pacman and makepkg,
On 08/23/2016 11:27 AM, Chi Hsuan Yen via aur-general wrote: though.
You can put whatever commands you want in package(), gtk or otherwise. Which I think is exactly what you are doing in regards to python.
The package() function is meant to separate the final step of copying over files into the pkg/ tree independent of everything else, ideally src/ should be treated as close to readonly as possible during package().
During the installation of a python package, it figures out the list of modules defined in setup.py and copies them into the right hierarchy in build/ as well as compiling any potential binary components. Then it copies the contents of the build/ hierarchy (whatever that may be, irrespective of the original source code) into the installation root.
Just because it is copying files around rather than running them through a C compiler, that makes it less of a build() sort of thing???
-- Eli Schwartz
Shamefully I didn't study the package guidelines carefully. I write PKGBUILDs for Python packages by copying from the (somewhat out-dated) Python PKGBUILD template [1], which is encouraging the wrong way. Official packages, like python-pip or python-virtualenv, use a similar approach too. [1] https://git.archlinux.org/abs.git/tree/prototypes/PKGBUILD-python.proto
On 08/23/2016 11:59 AM, Chi Hsuan Yen wrote:
Shamefully I didn't study the package guidelines carefully. I write PKGBUILDs for Python packages by copying from the (somewhat out-dated) Python PKGBUILD template [1], which is encouraging the wrong way. Official packages, like python-pip or python-virtualenv, use a similar approach too.
[1] https://git.archlinux.org/abs.git/tree/prototypes/PKGBUILD-python.proto
The ABS prototypes are out of date and the Wiki recommends you not use them. See also the bugtracker: https://bugs.archlinux.org/task/34485 Though I will acknowledge that my statement was a matter of personal logic and personal preference. I have actually seen it done both ways *for architecture-independent modules in the main repos*. So there is no formal consensus which way to do it, though naturally I cannont be expected to support the side I disagree with. :D -- Eli Schwartz
On August 23, 2016 3:11:55 PM GMT+02:00, Chi Hsuan Yen via aur-general <aur-general@archlinux.org> wrote:
At first I used split packages for python-* packages in my AUR repo. However, since pacman commit e8deba3b87784ca14c9afc908046f36a3ad7578c, [1][2] there's no way to build a subset of split packages. That is, people who use Python 3 (or Python 2) only need to install both Python versions to build my package. It would be nice if I can use a single PKGBUILD and build only a subset of split packages with makepkg.
Effectively (without any intend to blame or offend you) but you are very aware of this and simply ignore it on purpose. Its not really ideal to not use split packages just because you don't want people who build it to install both variants of the dependencies. If people don't want those in your/their system, then you/they should build it in a chroot (which I recommend either way). I get your point but I still recommend unifying those into a split package and conform decisions that are made. I don't see where building both variants is too much of a hassle. Those should be optimized in a way to be as sane related to structuring and building as possible and not how convenient it is to install it via wrapper X directly out of the AUR. It should be considered more like a staging area for the regular repositories, following its rules. It's always a hassle to invest a day before being able to move a package from the AUR just because they follow something else like not using split packages etc. cheers, Levente
On Tue, Aug 23, 2016 at 10:38 PM, Levente Polyak <anthraxx@archlinux.org> wrote:
On August 23, 2016 3:11:55 PM GMT+02:00, Chi Hsuan Yen via aur-general < aur-general@archlinux.org> wrote:
At first I used split packages for python-* packages in my AUR repo. However, since pacman commit e8deba3b87784ca14c9afc908046f36a3ad7578c, [1][2] there's no way to build a subset of split packages. That is, people who use Python 3 (or Python 2) only need to install both Python versions to build my package. It would be nice if I can use a single PKGBUILD and build only a subset of split packages with makepkg.
Effectively (without any intend to blame or offend you) but you are very aware of this and simply ignore it on purpose.
Its not really ideal to not use split packages just because you don't want people who build it to install both variants of the dependencies. If people don't want those in your/their system, then you/they should build it in a chroot (which I recommend either way).
Using clean chroots is definitely the best way to build a package, while it may not be practical for ordinary users. Installing a chroot takes quite a few minutes, lots of network usage and several hunders of megabytes, which is a high burden if I just need a package with 1MB.
I get your point but I still recommend unifying those into a split package and conform decisions that are made. I don't see where building both variants is too much of a hassle. Those should be optimized in a way to be as sane related to structuring and building as possible and not how convenient it is to install it via wrapper X directly out of the AUR.
Others may not agree, but for me making things easy to use is as important as making things clean. With that in mind, I always try my best to keep my AUR packages building fine in clean chroots as well as "dirty" systems with numerous unnecessary packages.
It should be considered more like a staging area for the regular repositories, following its rules. It's always a hassle to invest a day before being able to move a package from the AUR just because they follow something else like not using split packages etc.
cheers, Levente
Not quite agree. How AUR works is different from how official repositories do. How packages are installed is an important factor in those differences.
On 08/23/2016 11:03 AM, Chi Hsuan Yen via aur-general wrote:
Using clean chroots is definitely the best way to build a package, while it may not be practical for ordinary users. Installing a chroot takes quite a few minutes, lots of network usage and several hunders of megabytes, which is a high burden if I just need a package with 1MB.
Not really true. `arch-nspawn`, which `makechrootpkg` uses instead of chroot, will bind-mount the pacman cache into the systemd-nspawn container. As a result, most packages will not need to be downloaded, since they were already downloaded when you installed them on your system. Any packages which were not already downloaded, would need to be downloaded my makepkg anyway. Granted, setting up a chroot still takes time and disk space. Also keep in mind, though, that chroots can be reused. ... It doesn't really matter. `makepkg -sr` works just as well to get rid of unwanted makedepends after building. The *only* reason for wanting to avoid split PKGBUILDs is to avoid the burden of having to build both packages if you only need one of them. Any and every other consideration can and should be ameliorated simply by knowing how to properly use the tools you are provided. -- Eli Schwartz
Hi all,
Christoph Gysin came up with the problem of split packages that conflict each other, which is implementable in a PKGBUILD.
As an example consider https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pasystray which defines pasystray and pasystray-gtk2 which cannot be installed both at the same time. Neither aura nor yaourt supports such packages.
There is no other package known to me, but there should be some clarification, whether such a package is allowed.
In my opinion, already the name "split package" indicates that these should not conflict, otherwise it would not just be a split package, but rather something like a "versioned package".
In order to come to a conclusion for the discussion in the comments of that AUR package, I would kindly ask you for your thoughts concerning this problem.
Best, Lukas
Hello, I think Christoph is completely right here. The only issue I have with his PKGBUILD is that the conflict line should appear in both package functions and indicate the conflict to the other package. yaourt and aura are unsupported tools. But I am not a TU anymore. Best Regards Stefan
On 22/08/16 21:58, stefan-husmann@t-online.de wrote:
The only issue I have with his PKGBUILD is that the conflict line should appear in both package functions and indicate the conflict to the other package.
IMO the onus of conflicting should only be on the non-standard/modified package (i.e. the -gtk2 package). -- Regards, Rob McCathie
On 08/22/2016 01:58 PM, stefan-husmann@t-online.de wrote:
In my opinion, already the name "split package" indicates that these should not conflict, otherwise it would not just be a split package, but rather something like a "versioned package".
that's wrong, split packages are there to build multiple packages from a single source without the need to duplicate PKGBUILD that use the very same source.
I think Christoph is completely right here. The only issue I have with his PKGBUILD is that the conflict line should appear in both package functions and indicate the conflict to the other package.
That's not needed, not everything needs cross-conflicting to all other packages providing the same. In your example you simply add to your pasystray-gtk2 package() function that it conflicts and provides pasystray, thats it. The pasystray does not need to know anything about the gtk2 variant.
yaourt and aura are unsupported tools.
Totally right and its irrelevant how well those tools support such cases. cheers, Levente
-----Original-Nachricht----- Betreff: Re: [aur-general] Split packages Datum: 2016-08-23T11:26:07+0200 Von: "Levente Polyak" <anthraxx@archlinux.org> An: "aur-general@archlinux.org" <aur-general@archlinux.org>
On 08/22/2016 01:58 PM, stefan-husmann@t-online.de wrote:
In my opinion, already the name "split package" indicates that these should not conflict, otherwise it would not just be a split package, but rather something like a "versioned package".
that's wrong, split packages are there to build multiple packages from a single source without the need to duplicate PKGBUILD that use the very same source. It was not me who wrote that.
I think Christoph is completely right here. The only issue I have with his PKGBUILD is that the conflict line should appear in both package functions and indicate the conflict to the other package.
That's not needed, not everything needs cross-conflicting to all other packages providing the same. In your example you simply add to your pasystray-gtk2 package() function that it conflicts and provides pasystray, thats it. The pasystray does not need to know anything about the gtk2 variant.
That is exactly what I wanted to say. Best Regards, Stefan
On Mon, 22 Aug 2016 12:53:04 +0200 Lukas Mosimann <mlukas@ethz.ch> wrote:
Hi all,
Christoph Gysin came up with the problem of split packages that conflict each other, which is implementable in a PKGBUILD.
As an example consider https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pasystray which defines pasystray and pasystray-gtk2 which cannot be installed both at the same time. Neither aura nor yaourt supports such packages.
There is no other package known to me, but there should be some clarification, whether such a package is allowed.
In my opinion, already the name "split package" indicates that these should not conflict, otherwise it would not just be a split package, but rather something like a "versioned package".
In order to come to a conclusion for the discussion in the comments of that AUR package, I would kindly ask you for your thoughts concerning this problem.
Best, Lukas
While I'm not a fan, it's a valid PKGBUILD, there's a number of them in the repos like this. If your helper can't handle it, it's the helper's problem.
participants (9)
-
Bruno Pagani
-
Chi Hsuan Yen
-
Doug Newgard
-
Eli Schwartz
-
Levente Polyak
-
Lukas Mosimann
-
Rob McCathie
-
stefan-husmann＠t-online.de
-
Vanush Misha Paturyan