Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#54342 - [python-unicodecsv] bring back python-unicodecsv (PY3) package

Attached to Project: Community Packages
Opened by Carl George (carlwgeorge) - Wednesday, 07 June 2017, 14:18 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 10 July 2017, 04:08 GMT
Task Type General Gripe
Category Packages
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/python-unicodecsv&id=2384376a63dd2ec21701468aea6ac850ab8d8aaf

In this commit the python-unicodecsv Python 3 package was removed. That package is still needed. The setup.py file explicitly lists Python 3 support. I'm trying to build another package (python-rows) in the AUR, and it requires unicodecsv on both Python 2 and Python 3.

Additional info:

* 0.14.1-3
This task depends upon

Closed by  Doug Newgard (Scimmia)
Monday, 10 July 2017, 04:08 GMT
Reason for closing:  Not a bug
Comment by Carl George (carlwgeorge) - Thursday, 06 July 2017, 15:46 GMT
The existence of this package in community blocks me from submitting a python3 only version to the AUR. If the community package is going to block the namespace, at least have it provide both the py2 and py3 packages.
Comment by Doug Newgard (Scimmia) - Friday, 07 July 2017, 14:28 GMT
What problem are you having adding it to the AUR, exactly?
Comment by Carl George (carlwgeorge) - Saturday, 08 July 2017, 21:42 GMT
The normal process to create an AUR package is to clone a non-existent package name. That gives you an empty repo that you can commit your PKGBUILD and .SRCINFO files to, then when you do a git push the new package shows up in the AUR. However, the python-unicodecsv package previously existed in the AUR, so when you clone it from the AUR, instead of getting an empty repo, you get the previous package source before it was added to community. Doing a git push on that repo then has no effect on the AUR.

I really don't understand what's so difficult about this. Having a pkgbase of python-unicodecsv in community prevents the existence of that pkgbase in the AUR, so have the community package provide both the py2 and py3 packages.
Comment by Doug Newgard (Scimmia) - Sunday, 09 July 2017, 02:58 GMT
So no error? Seems more like user error in that case.
Comment by Carl George (carlwgeorge) - Sunday, 09 July 2017, 05:22 GMT
How in the world is that user error? You aren't making sense. The package existed in the AUR. It was removed and moved to community. Then the PY3 subpackage was removed from the PKGBUILD. Since it was removed from the AUR that pkgbase name is blacklisted and can't be added to the AUR again.
Comment by Doug Newgard (Scimmia) - Sunday, 09 July 2017, 05:34 GMT
Nothing you've posted points to the package being blacklisted. Post some real info, or I'll just close this again.
Comment by Eli Schwartz (eschwartz) - Sunday, 09 July 2017, 06:11 GMT
Carl, aurweb will only check the new commits you append to the repo history, and I am fairly positive that OfficialProviders should only be populated with (and therefore blacklist) the actual pkgnames in the repos, not pkgbases that don't actually build the same pkgname.

So this should work. If you've tried it and it doesn't work, consider filing an aurweb bug and/or posting to the aur-dev mailing list. :)
If you've tried pushing a combined py2/py3 split PKGBUILD, *which is what cloning + pushing would do if you haven't added a new commit to remove the py2 version*, then of course the AUR will rightly reject your attempt to push a duplicate python2-unicodecsv pkgname.

...

That being said, the idea of providing a split package in community rather than having the py2 version in community and the py3 version in the AUR, seems fairly reasonable to me.
Other py3 modules which aren't needed by anything but which have a py2 version in the repos, were added as split packages so there would seem to be precedence.
EDIT: Reasonable does not mean required though... that would be entirely at felixonmars' discretion.

Loading...