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 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 Tue, Aug 23, 2016 at 7:32 PM, Levente Polyak 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 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 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 08/23/2016 04:57 PM, Doug Newgard wrote:

On Tue, 23 Aug 2016 10:43:25 -0400 Eli Schwartz via aur-general 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 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 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 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 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 Tue, Aug 23, 2016 at 10:38 PM, Levente Polyak 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/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