Re: [aur-general] Split packages
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
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
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
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
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
Re: [aur-general] Split packages
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
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
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
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
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
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
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
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
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
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
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
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
>-Original-Nachricht- >Betreff: Re: [aur-general] Split packages >Datum: 2016-08-23T11:26:07+0200 >Von: "Levente Polyak" >An: "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
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
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
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
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 27 packages missing signoffs * 12 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (2 total) == * virtualbox-modules-arch-5.1.4-2 (i686) * virtualbox-modules-arch-5.1.4-2 (x86_64) == Incomplete signoffs for [community] (25 total) == * python-foolscap-0.12.1-1 (any) 0/2 signoffs * python-pytest-3.0.0-1 (any) 0/2 signoffs * python-sphinx-1.4.6-1 (any) 0/2 signoffs * acpi_call-1.1.0-49 (i686) 0/1 signoffs * bbswitch-0.8-53 (i686) 0/1 signoffs * cutegram-2.9.5-2 (i686) 0/1 signoffs * iscan-2.30.2-1 (i686) 0/1 signoffs * libqtelegram-ae-3:10.0.0-1 (i686) 0/1 signoffs * luasec-2:0.6-1 (i686) 0/1 signoffs * r8168-8.042-4 (i686) 0/1 signoffs * telegramqml-2.0.0-1 (i686) 0/1 signoffs * tp_smapi-0.42-3 (i686) 0/1 signoffs * vhba-module-20140928-33 (i686) 0/1 signoffs * virtualbox-modules-arch-5.1.4-2 (i686) 0/1 signoffs * acpi_call-1.1.0-49 (x86_64) 0/2 signoffs * bbswitch-0.8-53 (x86_64) 0/2 signoffs * cutegram-2.9.5-2 (x86_64) 1/2 signoffs * iscan-2.30.2-1 (x86_64) 0/2 signoffs * libqtelegram-ae-3:10.0.0-1 (x86_64) 1/2 signoffs * luasec-2:0.6-1 (x86_64) 1/2 signoffs * r8168-8.042-4 (x86_64) 0/2 signoffs * telegramqml-2.0.0-1 (x86_64) 1/2 signoffs * tp_smapi-0.42-3 (x86_64) 0/2 signoffs * vhba-module-20140928-33 (x86_64) 0/2 signoffs * virtualbox-modules-arch-5.1.4-2 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (2 total) == * aseman-qt-tools-1.0.0-1 (i686) 0/1 signoffs * aseman-qt-tools-1.0.0-1 (x86_64) 1/2 signoffs == All packages in [community-testing] for more than 14 days (12 total) == * iscan-2.30.2-1 (x86_64), since 2016-07-10 * iscan-2.30.2-1 (i686), since 2016-07-10 * aseman-qt-tools-1.0.0-1 (i686), since 2016-07-13 * aseman-qt-tools-1.0.0-1 (x86_64), since 2016-07-13 * libqtelegram-ae-3:10.0.0-1 (i686), since 2016-07-13 * libqtelegram-ae-3:10.0.0-1 (x86_64), since 2016-07-13 * telegramqml-2.0.0-1 (i686), since 2016-07-13 * telegramqml-2.0.0-1 (x86_64), since 2016-07-13 * cutegram-2.9.5-2 (i686), since 2016-07-13 * cutegram-2.9.5-2 (x86_64), since 2016-07-13 * luasec-2:0.6-1 (i686), since 2016-07-14 * luasec-2:0.6-1 (x86_64), since 2016-07-14 == Top five in signoffs in last 24 hours == 1. hcartiaux - 6 signoffs 2. eworm - 2 signoffs 3. polyzen - 1 signoffs