On Sat, Sep 29, 2018 at 7:57 PM Konstantin Gizdov wrote:

- How can I effectively communicate the nuts & bolts to the new maintenaners so to say, to make sure users still get what's expected?

There's precedence for maintainers of specialized software in the AUR to be sponsored to become a Trusted User (though it seems there's a preexisting relationship?).

- Is there anything I can do if new packages do not meet what the original

intention was - apart from making a conflicting AUR package?

The other option would be to host your own repo for these packages. -- Best, polyzen

On 9/29/18 3:57 PM, Konstantin Gizdov wrote:

Hi all,

I'm writing to hopefully get some clarity on some packages that I maintained in AUR (python-awkward-array, unuran), but have been overtaken now in [community]. Also one other package that I have not maintained 'libafterimage', but dear to me.

Firstly, thanks to Felix Yan for picking them up and sorry if the following questions have been asked before and obvious to everyone.

This is what I know:

1. Nothing in the core repos depends on them and they are libraries. I've not seen requests to add them before.

As mentioned above, this isn't a requirement, if a Dev/TU wishes to add them simply as a useful library this is fine.

2. 'libafterimage' includes a bug that has been reported to AUR, but has not been fixed. I've had to include a patch in my local chain.

https://bugs.archlinux.org/task/60246 was incorrectly closed then, especially as my first attempt to build it with extra-x86_64-build resulted in /usr/bin/mkdir /build/libafterimage/pkg/libafterimage/usr/include /usr/bin/mkdir: cannot create directory ‘/build/libafterimage/pkg/libafterimage/usr/include’: No such file or directory failed to create include directory: /build/libafterimage/pkg/libafterimage/usr/include Followed by this terrible build system *incorrectly* continuing to package the libs and binaries only.

3. The packages do not provide the same functionality as before, but conflict with the AUR ones. 4. I wasn't told anything - my AUR package was deleted with a 'thanks for maintaining it' message.

This is fairly common -- while it is nice to get in touch with the AUR maintainer, we hardly need *permission* to package something for the repos. As always, you can report bugs with the official packages.

5. I've reported a few bugs FS#6024{6,7,8}, but have been denied resolution.

Denied resolution? One bug was improperly closed and I've reopened it (that's why you can request this) One bug was simply completely wrong -- we don't have to provide the python2 version and it's 100% legitimate to maintain that in the AUR. If you think about it, you essentially *complained* that we only moved one of two packages to the official repos. How is that a legitimate complaint? One bug isn't even a bug, it's a feature request and moreover it's still open *and* it's assigned, pending resolution. I fail to see how you're being "denied" anything.

The reason I'm asking is because over the years I've added and been maintaining some professional software and these packages are part of that chain. Colleagues in the field have become accustomed to me for packaging with care and updating with new features. But now, obviously that is changing and people are going to flock if something doesn't work as expected. So this is sort of me getting ahead of the wind and basically asking the question:

This is definitely you getting ahead of something. :(

- Why? - How many & which will be put into [community]?

Whatever we want.

- How can I effectively communicate the nuts & bolts to the new maintenaners so to say, to make sure users still get what's expected?

A well-maintained PKGBUILD that gets added to [community] will naturally come with whatever well-written fixes were in that PKGBUILD. Apparently libafterimage was not well-maintained... Also python-awkward-array is not very well maintained either, judging by its erroneous use of completely invalid PKGBUILD syntax. I'd like to observe that while package_*() exists for split packages, there is no such thing as build_*() and we will reject any attempt at adding such functionality to makepkg. Your PKGBUILD therefore has no build function at all -- it goes right from prepare to package, and has the additional misfortune of not having the vitally required makedepends. You don't get to act as some sort of concerned citizen here to protect your packages from the incompetent Devs/TUs when your PKGBUILD contains this junk. (Sorry for being harsh, but this is the reaction you invite when you set yourself up as the superior packager.)

- Is there anything I can do if new packages do not meet what the original intention was - apart from making a conflicting AUR package?

No, and you don't get to make duplicate packages either. Submit a bugreport instead. If the package in question legitimately contains additional compile-time dependencies, then and only then may you make an AUR package called, for example, libfoo-optionalfeaturename. The actual package name that exists in the repos will be automatically blacklisted by the aurweb server. -- Eli Schwartz Bug Wrangler and Trusted User