[aur-general] Questions about some of my packages being adopted in [community]

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20180929/c660ea1f/attachment.asc>