[aur-requests] [PRQ#16875] Deletion Request for gtk3-classic
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/
On 03/12/2019 18:26, notify@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]). 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. J [1] https://github.com/krumelmonster/gtk3-mushrooms/pull/26
On 03/12/2019 19:27, Jonathon Fernyhough wrote:
It's not a simply a more up-to-date package. -snip-
Oh, it also packages `lib32-gtk3-classic` where there is no equivalent `lib32-gtk3-mushrooms` J
On 12/3/19 2:27 PM, Jonathon Fernyhough wrote:
On 03/12/2019 18:26, notify@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=packa...
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.
-- Eli Schwartz Bug Wrangler and Trusted User
On 12/3/19 9:13 PM, Eli Schwartz via aur-requests wrote:
On 12/3/19 2:27 PM, Jonathon Fernyhough wrote:
On 03/12/2019 18:26, notify@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=packa...
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.
As far as i could see by a quick inspection there does appear to be a difference in the patches applied as well, hence me rejecting the request. If this is actually not the case, we might have to revisit my decision -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 12/3/19 3:23 PM, Robin Broda via aur-requests wrote:
As far as i could see by a quick inspection there does appear to be a difference in the patches applied as well, hence me rejecting the request.
If this is actually not the case, we might have to revisit my decision
I haven't looked at them, figured it would be easier to ask the person who uploaded them. :p -- Eli Schwartz Bug Wrangler and Trusted User
Request #16875 has been rejected by coderobe [1]: not identical as pointed out on the ML [1] https://aur.archlinux.org/account/coderobe/
participants (4)
-
Eli Schwartz
-
Jonathon Fernyhough
-
notify＠aur.archlinux.org
-
Robin Broda