Re: [aur-general] Split packages

[Eli Schwartz via aur-general]

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

Re: [aur-general] Split packages

[Eli Schwartz via aur-general]

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

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

On Tue, Aug 23, 2016 at 11:41 PM, Eli Schwartz via aur-general <
aur-general@archlinux.org> wrote:

> 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
>

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

Re: [aur-general] Split packages

[Doug Newgard]

On Tue, 23 Aug 2016 11:33:38 -0400
Eli Schwartz via aur-general  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.

Re: [aur-general] Split packages

[Eli Schwartz via aur-general]

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

Re: [aur-general] Split packages

[Doug Newgard]

On Tue, 23 Aug 2016 17:09:05 +0200
Levente Polyak  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  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.

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

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
>

Re: [aur-general] Split packages

[Eli Schwartz via aur-general]

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

Re: [aur-general] Split packages

[Levente Polyak]

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.

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

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.

Re: [aur-general] Split packages

[Doug Newgard]

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.

Re: [aur-general] Split packages

[Eli Schwartz via aur-general]

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

Re: [aur-general] Split packages

[Levente Polyak]

On August 23, 2016 4:24:25 PM GMT+02:00, Chi Hsuan Yen via aur-general 
 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 

Re: [aur-general] Split packages

[Levente Polyak]

On August 23, 2016 3:11:55 PM GMT+02:00, 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.
>

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

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

On Tue, Aug 23, 2016 at 10:10 PM, Eli Schwartz via aur-general <
aur-general@archlinux.org> wrote:

> 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
>

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.

Re: [aur-general] Split packages

[Eli Schwartz via aur-general]

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

Re: [aur-general] Split packages

[stefan-husm...@t-online.de]

>-Original-Nachricht-
>Betreff: Re: [aur-general] Split packages
>Datum: 2016-08-23T11:26:07+0200
>Von: "Levente Polyak" <anthr...@archlinux.org>
>An: "aur-general@archlinux.org" <aur-general@archlinux.org>

>On 08/22/2016 01:58 PM, stefan-husm...@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

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

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

Re: [aur-general] Split packages

[Levente Polyak]

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



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Split packages

[Levente Polyak]

On 08/22/2016 01:58 PM, stefan-husm...@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



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Split packages

[Rob McCathie via aur-general]

On 22/08/16 21:58, stefan-husm...@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

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

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_template.py

Re: [aur-general] Split packages

[Vanush Misha Paturyan via aur-general]

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

Re: [aur-general] Split packages

[Doug Newgard]

On Mon, 22 Aug 2016 12:53:04 +0200
Lukas Mosimann  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.

Re: [aur-general] Split packages

[stefan-husm...@t-online.de]

>
>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

Re: [aur-general] Split packages

[Bruno Pagani]

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.

Regards,
Bruno

[aur-general] Split packages

[Lukas Mosimann]

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