[aur-requests] [PRQ#16875] Deletion Request for gtk3-classic

[Eli Schwartz]

On 12/3/19 2:27 PM, Jonathon Fernyhough wrote:
> On 03/12/2019 18:26, notify at aur.archlinux.org wrote:
>> rober_k [1] filed a deletion request for gtk3-classic [2]:
>>
>> this is an identical package as gtk3-mushrooms .
>> It pulls from the same repo, only is newer.
>> Proper way would be to mark gtk3-mushrooms out-of-date, not just
>> upload a different package with same content ;)
>>
>> [1] https://aur.archlinux.org/account/rober_k/
>> [2] https://aur.archlinux.org/pkgbase/gtk3-classic/
>>
> 
> It's not a simply a more up-to-date package. The source repo is the same
> but gtk3-classic is essentially a forked gtk3-mushrooms which adds
> experimental/developmental (?) aspects to the PKGBUILD which the
> original does not (e.g. use of meson and quilt, see e.g. [1]).

"Use quilt and meson" is not a valid reason to upload a new PKGBUILD.
The resulting package does not care what technology you use for applying
patches, and it *should* not care whether you use autotools or meson to
generate a series of compilation commands.

Is there something that the resulting .pkg.tar.xz does, which is
different from "gtk3-mushrooms"?

If it is just about the lib32-* variant, you can just upload a
lib32-gtk3-mushrooms package inspired by
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/lib32-gtk3

> Also, technically the gtk3-mushrooms package is not out-of-date as the
> upstream is still at 3.24.11.
> 
> If all of this is potentially too confusing let me update the PKGBUILD
> to use a different source rather than having the package deleted.

I don't think changing the url= field makes a difference, if that is
what you mean.

> [1] https://github.com/krumelmonster/gtk3-mushrooms/pull/26
> 


-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-requests/attachments/20191203/d5e826f8/attachment.sig>