Hi,
I'm looking forward to have the python library viivakoodi[0] as an Arch Linux packages. If I am not miss-lead this library does not exist in the Arch Linux repositories nor in AUR.
Use-case -------- I'm building this package to be able to use scripts provided into the mooltipass framework[1]. I personally hate the pip thing so I would appreciate to have it directly as an Arch Linux packages.
Description ----------- I comes with a PKGBUILD that could be found attached to this email or directly to my personal git repository[2].
As this is my first PKGBUILD (and contribution) I would appreciate any criticisms on this.
I came up with the following points by my own: * I'm not sure that the way I install the LICENSE file in the package_*() functions is the way it should be done. * As it is stated into the project README[3] argparse is required for python 2.6, 3.0 and 3.1. What is the good way to do this into a PKGBUILD ? I opt to force argparse as dependencies so I am sure that it should runs for everyone. * I have decided to introduce my custom variable _pylibname, I hope it would be okay. * Upstream does not provide any GPG signature of the tarballs nor commit signature. I've chosen to provide a detached GPG signature of the downloaded tarball with my GPG key. For me, its better to have this link-ability between the package maintainer and the downloaded tarball than nothing at all.
Do you have comments or anything ? Thanks for helping me and reviewing.
Q.
[0] https://github.com/kxepal/viivakoodi [1] https://github.com/limpkin/mooltipass/tree/master/tools/_python_framework [2] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/ [3] https://github.com/kxepal/viivakoodi/blob/master/README.rst
* Quentin Bourgeois quentin@bourgeois.eu [2016-11-26 03:03:02 +0100]:
- As it is stated into the project README[3] argparse is required
for python 2.6, 3.0 and 3.1. What is the good way to do this into a PKGBUILD ? I opt to force argparse as dependencies so I am sure that it should runs for everyone.
You don't. Partial updates are unsupported on Arch, so you can be sure Arch linux users use Python 2.7 or 3.5.
- Upstream does not provide any GPG signature of the tarballs nor
commit signature. I've chosen to provide a detached GPG signature of the downloaded tarball with my GPG key. For me, its better to have this link-ability between the package maintainer and the downloaded tarball than nothing at all.
Not sure if that makes much sense, and FWIW I've had some issues with people not being able to install AUR packages with PGP keys. I don't recall exactly what the problem was though...
groups=() depends=() makedepends=() provides=() conflicts=() replaces=() backup=() options=() install= changelog=
You can remove empty variables ;)
optdepends=('inkscape: tools for manipulating vector objects (eg: SVG files)')
You'd usually put an explanation when/why inkscape is needed here.
checkdepends=('python-tox' 'python-pylint' 'python2-tox' 'python2-pylint')
I don't think it makes sense to run pylint during check(). It tells you nothing about if the package is working correctly or not.
sha256sums=('e1a17dc24975d5242202cfbb7534d69dd14eeb26bdf8a10f056c7b04904fef1e' 'c161bd90708ca20c841321139f7e8fe5ae53cb25f55d0327fea5b59ac401f8e9') sha384sums=('e2da627423221298dfc55be93ab07e42d8801f0fa63bcfc5ad6bfa689181bcd0e7eb9525abdfd20aa3637ae56999956b' 'b92e09d3e801b55ec97e28b105d8033d6bace8fc869343331e1093bbb35aabe201432e43ea4487014c92b190a65c89f8') sha512sums=('b9f5fc859b3ec33a1cf264d5ede597ff79cd447043668cf433096bf0bf89e24e1a8bf05f7914420934bc6c03a66ec0df99a203136c3f6506e0fda8e3c6f619fd' '68b6df665e76555489b9abc616fda11180c1c420e8a5dd74c191543335ee0b887fbba8115f7823aed676242b559af10141fc6a40c4b068a39b9e1038917dc29e')
No point in providing all of them - stick to one.
if [ -f LICENSE ]; then install -Dm0644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE" install -Dm0644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE.launcher" else warning "license file not found" fi
Why would it ever not exist?
Florian
On 11/26/2016 01:01 AM, Florian Bruhin wrote:
- Upstream does not provide any GPG signature of the tarballs nor
commit signature. I've chosen to provide a detached GPG signature of the downloaded tarball with my GPG key. For me, its better to have this link-ability between the package maintainer and the downloaded tarball than nothing at all.
Not sure if that makes much sense, and FWIW I've had some issues with people not being able to install AUR packages with PGP keys. I don't recall exactly what the problem was though...
This. GPG signatures are meant to prove that upstream really released it, but if all you know is that the AUR maintainer *thinks* this is the upstream release, you might as well just stick with checksums, which will serve just as well to prove the source code is the same source code the AUR maintainer used.
Anyone who can defeat the checksum (by modifying your PKGBUILD) can also defeat your own GPG key.
On 16-11-26 19:27:37, Eli Schwartz via aur-general wrote:
On 11/26/2016 01:01 AM, Florian Bruhin wrote:
- Upstream does not provide any GPG signature of the tarballs nor
commit signature. I've chosen to provide a detached GPG signature of the downloaded tarball with my GPG key. For me, its better to have this link-ability between the package maintainer and the downloaded tarball than nothing at all.
Not sure if that makes much sense, and FWIW I've had some issues with people not being able to install AUR packages with PGP keys. I don't recall exactly what the problem was though...
This. GPG signatures are meant to prove that upstream really released it, but if all you know is that the AUR maintainer *thinks* this is the upstream release, you might as well just stick with checksums, which will serve just as well to prove the source code is the same source code the AUR maintainer used.
Anyone who can defeat the checksum (by modifying your PKGBUILD) can also defeat your own GPG key.
You are right I have remove this, my first goals was to sign my PKGBUILD file I don't think its possible ?
On 16-11-26 07:01:15, Florian Bruhin wrote:
optdepends=('inkscape: tools for manipulating vector objects (eg: SVG files)')
You'd usually put an explanation when/why inkscape is needed here.
Inkscape (or any other tool for SVG handling) is needed if one would like to see the result of generated document in SVG format. As there could be a long list I am not sure if such dependencies should be put into PKGBUILD, even in optdepends ?
if [ -f LICENSE ]; then install -Dm0644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE" install -Dm0644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE.launcher" else warning "license file not found" fiWhy would it ever not exist?
I add this check in case upstream change for any reason and not break the build process. The warning should be enough to let me investigate. I generally don't perform operation on resource that could not be present, I just applied this here too.
Thanks for your feedback, I have updated the PKGBUILD[0].
[0] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
On 11/27/2016 10:30 AM, Quentin Bourgeois wrote:
You are right I have remove this, my first goals was to sign my PKGBUILD file I don't think its possible ?
No, although the AUR is HTTPS.
If people clone the package instead of downloading the snapshot (several AUR helpers can be configured to do that), and if they obtain your public key, they can use git to verify signed commits. Assuming they know you sign your commits. But no AUR helper tries to check that... and how would you know which key to trust?
Inkscape (or any other tool for SVG handling) is needed if one would like to see the result of generated document in SVG format. As there could be a long list I am not sure if such dependencies should be put into PKGBUILD, even in optdepends ?
Looking at the project README, it just generates an SVG file (and says you will need a program that opens SVG, like most browsers). It doesn't fundamentally integrate with Inkscape, and you should not add as a dependency every single program capable of opening a specific filetype. In fact, you shouldn't even add one such program. ;)
When it describes "Program to open SVG objects" as a requirement, they probably shouldn't have listed that in the code requirements, since it is only a *logical* requirement...
I add this check in case upstream change for any reason and not break the build process. The warning should be enough to let me investigate. I generally don't perform operation on resource that could not be present, I just applied this here too.
You should catch that when you make the package yourself before pushing an update to the AUR, since the install command would fail with an error and makepkg would abort with an error. At least, I assume you consume your own packages...
As a general rule, do not clutter up the PKGBUILD with things that can change from version to version unless it is a VCS package and the same PKGBUILD applies from version to version as new commits are pulled from the VCS source. Also, don't make checks like that for things which are really quite unlikely to change. Why do you think they might do that???
On 16-11-27 11:10:51, Eli Schwartz via aur-general wrote:
On 11/27/2016 10:30 AM, Quentin Bourgeois wrote:
You are right I have remove this, my first goals was to sign my PKGBUILD file I don't think its possible ?
No, although the AUR is HTTPS.
If people clone the package instead of downloading the snapshot (several AUR helpers can be configured to do that), and if they obtain your public key, they can use git to verify signed commits. Assuming they know you sign your commits. But no AUR helper tries to check that... and how would you know which key to trust?
Inkscape (or any other tool for SVG handling) is needed if one would like to see the result of generated document in SVG format. As there could be a long list I am not sure if such dependencies should be put into PKGBUILD, even in optdepends ?
Looking at the project README, it just generates an SVG file (and says you will need a program that opens SVG, like most browsers). It doesn't fundamentally integrate with Inkscape, and you should not add as a dependency every single program capable of opening a specific filetype. In fact, you shouldn't even add one such program. ;)
When it describes "Program to open SVG objects" as a requirement, they probably shouldn't have listed that in the code requirements, since it is only a *logical* requirement...
I add this check in case upstream change for any reason and not break the build process. The warning should be enough to let me investigate. I generally don't perform operation on resource that could not be present, I just applied this here too.
You should catch that when you make the package yourself before pushing an update to the AUR, since the install command would fail with an error and makepkg would abort with an error. At least, I assume you consume your own packages...
As a general rule, do not clutter up the PKGBUILD with things that can change from version to version unless it is a VCS package and the same PKGBUILD applies from version to version as new commits are pulled from the VCS source. Also, don't make checks like that for things which are really quite unlikely to change. Why do you think they might do that???
With this, I come with a simpler PKGBUILD[0] in which I push modifications you advised. I also removed some dependencies that are used for code coverage and building documentation, which I do not install for now.
Did we get to something good ?
[0] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
On 11/27/2016 06:10 PM, Quentin Bourgeois wrote:
With this, I come with a simpler PKGBUILD[0] in which I push modifications you advised. I also removed some dependencies that are used for code coverage and building documentation, which I do not install for now.
Did we get to something good ?
[0] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
Err, why do both split packages provide 'python2-viivakoodi'? One of them already is 'python2-viivakoodi', and the other by definition doesn't supply it, being Python 3.
You declare setuptools as a makedepends only, but I hate to inform you that setuptools-installed packages have a runtime dependency on setuptools to launch their console scripts. (This is the downside of having python itself be capable of generating the entry point launchers in a cross-platform manner -- rather than using your own python scripts with file extensions, then assuming Linux users will be happy with the extension and Windows users will be able to launch a non-binary.)
For module-only python packages, it is only a makedepends... for packages which ship with console_scripts you need it at runtime as well, otherwise the console_scripts will fail trying to import pkg_resources.
You can either have each split package depend on python{,2}-setuptools, or depend on both that and the python{,2} package itself. I have seen it done both ways.
...
There are still some optional style preferences, like leaving a line of whitespace after the "# Maintainer:" line and reusing the "$url" variable in the source array. Feel free to take that or leave it, though. :) Also, I don't usually see people initializing an array with += but it isn't like that is harmful. Also, the permissions mode in chmod/install assumes leading zeroes, so you don't need to explicitly say those licenses are lacking in suid/sticky attributes.
On 16-11-27 19:41:06, Eli Schwartz via aur-general wrote:
On 11/27/2016 06:10 PM, Quentin Bourgeois wrote:
With this, I come with a simpler PKGBUILD[0] in which I push modifications you advised. I also removed some dependencies that are used for code coverage and building documentation, which I do not install for now.
Did we get to something good ?
[0] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
I should comes with all modification on this batch.
Err, why do both split packages provide 'python2-viivakoodi'? One of them already is 'python2-viivakoodi', and the other by definition doesn't supply it, being Python 3.
My mistake.
You declare setuptools as a makedepends only, but I hate to inform you that setuptools-installed packages have a runtime dependency on setuptools to launch their console scripts. (This is the downside of having python itself be capable of generating the entry point launchers in a cross-platform manner -- rather than using your own python scripts with file extensions, then assuming Linux users will be happy with the extension and Windows users will be able to launch a non-binary.)
For module-only python packages, it is only a makedepends... for packages which ship with console_scripts you need it at runtime as well, otherwise the console_scripts will fail trying to import pkg_resources.
You can either have each split package depend on python{,2}-setuptools, or depend on both that and the python{,2} package itself. I have seen it done both ways.
Hum, this was not abvious for me, thanks. With what I have understand from that I have decide to make every split package depend on pythonX and pythonX-setuptools its seem simpler for me to understand.
I will dig this setuptools + console_script topics by my own.
On this, when I run namcap on created packages I get some warnings:
$ namcap *.tar.xz python2-viivakoodi W: Dependency python2 included but already satisfied python2-viivakoodi W: Dependency included and not needed ('python2-setuptools') python-viivakoodi W: Dependency python included but already satisfied python-viivakoodi W: Dependency included and not needed ('python-setuptools')
For every packages the first warning is due to my choice. For the second does namcap could warn packager that are not aware of the setuptools+console_scripts things (or maybe its something well known ?).
...
There are still some optional style preferences, like leaving a line of whitespace after the "# Maintainer:" line and reusing the "$url" variable in the source array. Feel free to take that or leave it, though. :) Also, I don't usually see people initializing an array with += but it isn't like that is harmful. Also, the permissions mode in chmod/install assumes leading zeroes, so you don't need to explicitly say those licenses are lacking in suid/sticky attributes.
Integrated, the += intialization was due to the empty variables remove.
On style preferences, when I code in Bash I over use {} arround variables (mainly when variables are tied to other strings). What is the guideline on this ?
-- Eli Schwartz
On 11/28/2016 07:47 PM, Quentin Bourgeois wrote:
On 16-11-27 19:41:06, Eli Schwartz via aur-general wrote:
On 11/27/2016 06:10 PM, Quentin Bourgeois wrote:
With this, I come with a simpler PKGBUILD[0] in which I push modifications you advised. I also removed some dependencies that are used for code coverage and building documentation, which I do not install for now.
Did we get to something good ?
[0] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
I should comes with all modification on this batch.
Err, why do both split packages provide 'python2-viivakoodi'? One of them already is 'python2-viivakoodi', and the other by definition doesn't supply it, being Python 3.
My mistake.
You declare setuptools as a makedepends only, but I hate to inform you that setuptools-installed packages have a runtime dependency on setuptools to launch their console scripts. (This is the downside of having python itself be capable of generating the entry point launchers in a cross-platform manner -- rather than using your own python scripts with file extensions, then assuming Linux users will be happy with the extension and Windows users will be able to launch a non-binary.)
For module-only python packages, it is only a makedepends... for packages which ship with console_scripts you need it at runtime as well, otherwise the console_scripts will fail trying to import pkg_resources.
You can either have each split package depend on python{,2}-setuptools, or depend on both that and the python{,2} package itself. I have seen it done both ways.
Hum, this was not abvious for me, thanks. With what I have understand from that I have decide to make every split package depend on pythonX and pythonX-setuptools its seem simpler for me to understand.
I will dig this setuptools + console_script topics by my own.
Nooooo, put the combined setuptools makedepends back! makepkg usually includes depends=() in the resolved build-time dependencies, but for split packages which have depends=() declared in the package_* function, those do not get added to the build-time dependencies.
You can actually use that as a practical way to define rundepends -- runtime-only depends which don't need to be installed when building (which makepkg has no concept of and the developers aren't interested in especially considering there is a reasonable workaround).
So, many python packages end up with a makedepends on python{,2}-setuptools (to ensure building works) *and* a depends on setuptools in each package_* function.
Sorry, this must seem quite confusing with all this back and forth. :D On the other hand, think of everything you are learning...
On this, when I run namcap on created packages I get some warnings:
$ namcap *.tar.xz python2-viivakoodi W: Dependency python2 included but already satisfied python2-viivakoodi W: Dependency included and not needed ('python2-setuptools') python-viivakoodi W: Dependency python included but already satisfied python-viivakoodi W: Dependency included and not needed ('python-setuptools')
For every packages the first warning is due to my choice. For the second does namcap could warn packager that are not aware of the setuptools+console_scripts things (or maybe its something well known ?).
Namcap is meant to offer suggestions that may or may not be applicable. It should *never* be taken as gospel truth.
I am not sure how it figures out which python packages are "needed", although it usually does a pretty good job of checking shared library dependencies.
On style preferences, when I code in Bash I over use {} arround variables (mainly when variables are tied to other strings). What is the guideline on this ?
There are no guidelines, some people use them and some people don't. (Rather like bash itself, which also has its fiercely divided camps advocating competing style guides.) I myself prefer them, you are definitely not alone. :)
On 16-11-28 23:02:02, Eli Schwartz via aur-general wrote:
On 11/28/2016 07:47 PM, Quentin Bourgeois wrote:
On 16-11-27 19:41:06, Eli Schwartz via aur-general wrote:
On 11/27/2016 06:10 PM, Quentin Bourgeois wrote:
With this, I come with a simpler PKGBUILD[0] in which I push modifications you advised. I also removed some dependencies that are used for code coverage and building documentation, which I do not install for now.
Did we get to something good ?
[0] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
I should comes with all modification on this batch.
Err, why do both split packages provide 'python2-viivakoodi'? One of them already is 'python2-viivakoodi', and the other by definition doesn't supply it, being Python 3.
My mistake.
You declare setuptools as a makedepends only, but I hate to inform you that setuptools-installed packages have a runtime dependency on setuptools to launch their console scripts. (This is the downside of having python itself be capable of generating the entry point launchers in a cross-platform manner -- rather than using your own python scripts with file extensions, then assuming Linux users will be happy with the extension and Windows users will be able to launch a non-binary.)
For module-only python packages, it is only a makedepends... for packages which ship with console_scripts you need it at runtime as well, otherwise the console_scripts will fail trying to import pkg_resources.
You can either have each split package depend on python{,2}-setuptools, or depend on both that and the python{,2} package itself. I have seen it done both ways.
Hum, this was not abvious for me, thanks. With what I have understand from that I have decide to make every split package depend on pythonX and pythonX-setuptools its seem simpler for me to understand.
I will dig this setuptools + console_script topics by my own.
Nooooo, put the combined setuptools makedepends back! makepkg usually includes depends=() in the resolved build-time dependencies, but for split packages which have depends=() declared in the package_* function, those do not get added to the build-time dependencies.
You can actually use that as a practical way to define rundepends -- runtime-only depends which don't need to be installed when building (which makepkg has no concept of and the developers aren't interested in especially considering there is a reasonable workaround).
So, many python packages end up with a makedepends on python{,2}-setuptools (to ensure building works) *and* a depends on setuptools in each package_* function.
Ouch, one new try :p
Sorry, this must seem quite confusing with all this back and forth. :D On the other hand, think of everything you are learning...
Definitely, but its quiet fun to be faced with such problems. If you may I propose the following summary in order to assert that I am starting to get a bigger picture:
- setuptools related stuff Some project, like viivakoodi, needs setuptools for installation. In such case pythonX-setuptools is needed at build-time. * If we provide a split packages both python{,2}-setuptools should be included into makedepends() * If the project use *console_scripts* entry points pythonX-setuptools is needed as the runtime dependencies too.
- PKGBUILD/makepkg related stuff At built-time makepkg "merge" both makedepends() and depends(). * However, if we are building a split package with a depends() inside a package_* function, this depends() will not be watched at built-time. So packager must "copy" the content of package_* depends() into global makedepends() in that particular case.
On this, when I run namcap on created packages I get some warnings:
$ namcap *.tar.xz python2-viivakoodi W: Dependency python2 included but already satisfied python2-viivakoodi W: Dependency included and not needed ('python2-setuptools') python-viivakoodi W: Dependency python included but already satisfied python-viivakoodi W: Dependency included and not needed ('python-setuptools')
For every packages the first warning is due to my choice. For the second does namcap could warn packager that are not aware of the setuptools+console_scripts things (or maybe its something well known ?).
Namcap is meant to offer suggestions that may or may not be applicable. It should *never* be taken as gospel truth.
I am not sure how it figures out which python packages are "needed", although it usually does a pretty good job of checking shared library dependencies.
On style preferences, when I code in Bash I over use {} arround variables (mainly when variables are tied to other strings). What is the guideline on this ?
There are no guidelines, some people use them and some people don't. (Rather like bash itself, which also has its fiercely divided camps advocating competing style guides.) I myself prefer them, you are definitely not alone. :)
-- Eli Schwartz
On 11/29/2016 08:19 PM, Quentin Bourgeois wrote:
Ouch, one new try :p
Looks good to me. I'd say it is ready to upload to the AUR.
Definitely, but its quiet fun to be faced with such problems.
It's also quite fun even when you're loud. ;)
If you may I propose the following summary in order to assert that I am starting to get a bigger picture:
- setuptools related stuff
Some project, like viivakoodi, needs setuptools for installation. In such case pythonX-setuptools is needed at build-time.
- If we provide a split packages both python{,2}-setuptools should
be included into makedepends()
- If the project use *console_scripts* entry points
pythonX-setuptools is needed as the runtime dependencies too.
- PKGBUILD/makepkg related stuff
At built-time makepkg "merge" both makedepends() and depends().
- However, if we are building a split package with a depends()
inside a package_* function, this depends() will not be watched at built-time. So packager must "copy" the content of package_* depends() into global makedepends() in that particular case.
Yup, that's about it. Predicated on the build needing all runtime dependencies installed, which is the case for setuptools.
It is worth noting purely for correctness, that the *console_scripts* spec also has a brother called *gui_scripts*, which is the same thing but indicates the script/exe should launch a GUI instead of existing in a terminal. (I guess that has a practical difference on Windows.)
While not referenced here because viivakoodi has none, projects that have *gui_scripts* display the same behavior -- setuptools is generating the *entry_points* ==> {console,gui}_scripts instead of using the user-supplied *scripts* , and since setuptools generates it for you it embeds itself into the scene. I suppose this is useful for allowing it to check the *.egg-info/requires.txt at runtime, although distro packaging theoretically takes care of that for us.
On 16-11-29 23:59:45, Eli Schwartz via aur-general wrote:
On 11/29/2016 08:19 PM, Quentin Bourgeois wrote:
Ouch, one new try :p
Looks good to me. I'd say it is ready to upload to the AUR.
Hi,
I finally managed to upload to AUR[0]. I had to made some modification[1] in order to pass the different hooks on the server but I think they would be ok.
Thanks to you and Florian for showing me the way, I really appreciate.
Nevertheless it seems that I definitely need to change from yaourt to other AUR helper that supports split packages. :p
Definitely, but its quiet fun to be faced with such problems.
It's also quite fun even when you're loud. ;)
If you may I propose the following summary in order to assert that I am starting to get a bigger picture:
- setuptools related stuff
Some project, like viivakoodi, needs setuptools for installation. In such case pythonX-setuptools is needed at build-time.
- If we provide a split packages both python{,2}-setuptools should
be included into makedepends()
- If the project use *console_scripts* entry points
pythonX-setuptools is needed as the runtime dependencies too.
- PKGBUILD/makepkg related stuff
At built-time makepkg "merge" both makedepends() and depends().
- However, if we are building a split package with a depends()
inside a package_* function, this depends() will not be watched at built-time. So packager must "copy" the content of package_* depends() into global makedepends() in that particular case.
Yup, that's about it. Predicated on the build needing all runtime dependencies installed, which is the case for setuptools.
It is worth noting purely for correctness, that the *console_scripts* spec also has a brother called *gui_scripts*, which is the same thing but indicates the script/exe should launch a GUI instead of existing in a terminal. (I guess that has a practical difference on Windows.)
While not referenced here because viivakoodi has none, projects that have *gui_scripts* display the same behavior -- setuptools is generating the *entry_points* ==> {console,gui}_scripts instead of using the user-supplied *scripts* , and since setuptools generates it for you it embeds itself into the scene. I suppose this is useful for allowing it to check the *.egg-info/requires.txt at runtime, although distro packaging theoretically takes care of that for us.
Is it relevant to add some of this information (runtime deps on setuptools) ? I don't remember having seen such information while looking at the manpage/wiki. In the other hand I don't known if its obvious for other.
[0]: https://aur.archlinux.org/packages/python-viivakoodi/ https://aur.archlinux.org/packages/python2-viivakoodi/ [1]: https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/PKGBUILD?h=python-vi...
-- Eli Schwartz
On 12/01/2016 08:24 PM, Quentin Bourgeois wrote:
I finally managed to upload to AUR[0]. I had to made some modification[1] in order to pass the different hooks on the server but I think they would be ok.
So I see... especially the "every commit must have a .SRCINFO". I had kind of sort of assumed you would push the PKGBUILD you finally settled on as the initial PKGBUILD, but apparently you opted to preserve your learning experience for eternity. :p
Unfortunately that won't work, since your learning experience included a missing .SRCINFO which cannot be preserved. :D
Is it relevant to add some of this information (runtime deps on setuptools) ? I don't remember having seen such information while looking at the manpage/wiki. In the other hand I don't known if its obvious for other.
Which manpage/wiki?
I guess it is sort of assumed that people won't uninstall setuptools -- it is part of the python package manager scene (distutils -> setuptools -> pip) and in a way it sort of competes with pacman. "The standard library is where modules go to die" but nevertheless, I am pretty sure the setuptools developers would love to make sure everyone always has it, no matter what.
But I will admit it wasn't obvious to me... until I learned the basics of python module packaging.
On 16-12-01 21:57:08, Eli Schwartz via aur-general wrote:
On 12/01/2016 08:24 PM, Quentin Bourgeois wrote:
I finally managed to upload to AUR[0]. I had to made some modification[1] in order to pass the different hooks on the server but I think they would be ok.
So I see... especially the "every commit must have a .SRCINFO". I had kind of sort of assumed you would push the PKGBUILD you finally settled on as the initial PKGBUILD, but apparently you opted to preserve your learning experience for eternity. :p
Unfortunately that won't work, since your learning experience included a missing .SRCINFO which cannot be preserved. :D
Indeed, I did a pretty bad job with that, which, was not tested enough.
I will try to come up with a better solution by tomorrow.
Is it relevant to add some of this information (runtime deps on setuptools) ? I don't remember having seen such information while looking at the manpage/wiki. In the other hand I don't known if its obvious for other.
Which manpage/wiki?
I was thinking of the wiki page that give instruction with Python PKGBUILD[0].
I guess it is sort of assumed that people won't uninstall setuptools -- it is part of the python package manager scene (distutils -> setuptools -> pip) and in a way it sort of competes with pacman. "The standard library is where modules go to die" but nevertheless, I am pretty sure the setuptools developers would love to make sure everyone always has it, no matter what.
But I will admit it wasn't obvious to me... until I learned the basics of python module packaging.
-- Eli Schwartz
On 12/02/2016 08:04 PM, Quentin Bourgeois wrote:
On 16-12-01 21:57:08, Eli Schwartz via aur-general wrote:
On 12/01/2016 08:24 PM, Quentin Bourgeois wrote:
I finally managed to upload to AUR[0]. I had to made some modification[1] in order to pass the different hooks on the server but I think they would be ok.
So I see... especially the "every commit must have a .SRCINFO". I had kind of sort of assumed you would push the PKGBUILD you finally settled on as the initial PKGBUILD, but apparently you opted to preserve your learning experience for eternity. :p
Unfortunately that won't work, since your learning experience included a missing .SRCINFO which cannot be preserved. :D
Indeed, I did a pretty bad job with that, which, was not tested enough.
I will try to come up with a better solution by tomorrow.
That was a joke... I *don't* really think it is important to save the fact that you forgot the .SRCINFO, and after all there is a time and a place for `git filter-branch` (in fact, this is how many people migrated from AUR3 to AUR4).
But the right solution to the question "how can I enforce proper .SRCINFO, now I know I need them", is, as far as I am concerned, to emulate me. See: https://github.com/eli-schwartz/pkgbuilds
githooks are where it's at. ;)
On 12/02/2016 08:04 PM, Quentin Bourgeois wrote:
Which manpage/wiki?
I was thinking of the wiki page that give instruction with Python PKGBUILD[0].
Check that Wiki page again, I added a section on setuptools.
Suggestions are welcome, in case anyone reads this who is better at writing Wikis than I am; I make no promises...
On 16-12-03 19:38:13, Eli Schwartz via aur-general wrote:
On 12/02/2016 08:04 PM, Quentin Bourgeois wrote:
Which manpage/wiki?
I was thinking of the wiki page that give instruction with Python PKGBUILD[0].
Check that Wiki page again, I added a section on setuptools.
Suggestions are welcome, in case anyone reads this who is better at writing Wikis than I am; I make no promises...
Seems good to me, I just remove a word repitition. The section on setuptools is clear!
Thanks.
aur-general@lists.archlinux.org