[PRQ#49836] Deletion Request for lib32-gd
MarsSeed [1] filed a deletion request for lib32-gd [2]: lib32-gd is absolutely unnecessary for lib32-libgphoto2. The latter could only use gd for on-the-fly image conversion two specific digital "picture frame" hardware, for which libgphoto2 introduced support in 2015, well within the 64-bit era. Also that library is utilized for Docupen scanner pen support, starting from 2020. There is no other part of the libgphoto2 code that links to gd. Therefore I cannot conceive any application that is bin32 only and needs this specialized functionality of libgphoto2 for those 2015 and 2020 released, 64-bit compatible niche hardware devices. I've notified the maintainer of lib32-libgphoto2 about this in July 2023. Deleting this unneeded library would in turn allow other lib32 packages to be dropped. And also it would help reduce the dependency build burden on people who use AUR/wine-stable. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/lib32-gd/
There is no other part of the libgphoto2 code that links to gd.
that statement is not true at all https://github.com/search?q=repo%3Agphoto%2Flibgphoto2%20gd&type=code https://github.com/gphoto/libgphoto2/blob/807d44d0dcb0a8a8df151baa27830127fb... i think you need talk with upstream for why still keep this type of thing in the code if is not used greetings El dom, 29 oct 2023 a las 22:55, <notify@aur.archlinux.org> escribió:
MarsSeed [1] filed a deletion request for lib32-gd [2]:
lib32-gd is absolutely unnecessary for lib32-libgphoto2.
The latter could only use gd for on-the-fly image conversion two specific digital "picture frame" hardware, for which libgphoto2 introduced support in 2015, well within the 64-bit era. Also that library is utilized for Docupen scanner pen support, starting from 2020.
There is no other part of the libgphoto2 code that links to gd. Therefore I cannot conceive any application that is bin32 only and needs this specialized functionality of libgphoto2 for those 2015 and 2020 released, 64-bit compatible niche hardware devices.
I've notified the maintainer of lib32-libgphoto2 about this in July 2023.
Deleting this unneeded library would in turn allow other lib32 packages to be dropped. And also it would help reduce the dependency build burden on people who use AUR/wine-stable.
[1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/lib32-gd/
There is no other part of the libgphoto2 code that links to gd.
that statement is not true at all
https://github.com/search?q=repo%3Agphoto%2Flibgphoto2%20gd&type=code https://github.com/gphoto/libgphoto2/blob/807d44d0dcb0a8a8df151baa27830127fb...
Duh, of course the libgphoto2 configure script refers to gd / libgd. But this does not refute my statement. I've checked the entire source code of libgphoto2 for references, that's how I've found all the use cases of gd, and none of those are relevant in lib32. I'd suggest you do the same checking as I did if you are in doubt. The configure script of libgphoto2 let's one easily disable gd support. @sl1pkn07 I see the obvious pattern with you that you like to try to contradict others apparently just for the sake of it. But this kind of disagreement that you presented here is not a counterpoint at all. Also you seem to like to maintain newly introduced multimedia libraries in lib32 that have no use case whatsoever. You also tend to cling to extremely old, deprecated, discontinued software that have no users on AUR apart from you. Deleting lib32-gd of course will allow the deletion of lib32-libheif, a package you maintain in vain, because that also falls into the category of "too new, so no imaginable practical use cases at all in lib32". Please try, really try to refrain from coming up with moot arguments. Such things do not contribute anything useful to deciding the fate of packages, and the attitude behind it is also detrimental to the community as a whole. On 30 October 2023 01:35:05 GMT+01:00, sL1pKn07 SpinFlo <sl1pkn07@gmail.com> wrote:
There is no other part of the libgphoto2 code that links to gd.
that statement is not true at all
https://github.com/search?q=repo%3Agphoto%2Flibgphoto2%20gd&type=code https://github.com/gphoto/libgphoto2/blob/807d44d0dcb0a8a8df151baa27830127fb...
i think you need talk with upstream for why still keep this type of thing in the code if is not used
greetings
El dom, 29 oct 2023 a las 22:55, <notify@aur.archlinux.org> escribió:
MarsSeed [1] filed a deletion request for lib32-gd [2]:
lib32-gd is absolutely unnecessary for lib32-libgphoto2.
The latter could only use gd for on-the-fly image conversion two specific digital "picture frame" hardware, for which libgphoto2 introduced support in 2015, well within the 64-bit era. Also that library is utilized for Docupen scanner pen support, starting from 2020.
There is no other part of the libgphoto2 code that links to gd. Therefore I cannot conceive any application that is bin32 only and needs this specialized functionality of libgphoto2 for those 2015 and 2020 released, 64-bit compatible niche hardware devices.
I've notified the maintainer of lib32-libgphoto2 about this in July 2023.
Deleting this unneeded library would in turn allow other lib32 packages to be dropped. And also it would help reduce the dependency build burden on people who use AUR/wine-stable.
[1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/lib32-gd/
El vie, 24 nov 2023 a las 12:56, Marcell Meszaros (< marcell.meszaros@runbox.eu>) escribió:
There is no other part of the libgphoto2 code that links to gd.
that statement is not true at all
https://github.com/search?q=repo%3Agphoto%2Flibgphoto2%20gd&type=code
https://github.com/gphoto/libgphoto2/blob/807d44d0dcb0a8a8df151baa27830127fb...
Duh, of course the libgphoto2 configure script refers to gd / libgd. But this does not refute my statement.
I've checked the entire source code of libgphoto2 for references, that's how I've found all the use cases of gd, and none of those are relevant in lib32.
I'd suggest you do the same checking as I did if you are in doubt.
The configure script of libgphoto2 let's one easily disable gd support.
@sl1pkn07 I see the obvious pattern with you that you like to try to contradict others apparently just for the sake of it. But this kind of disagreement that you presented here is not a counterpoint at all.
Also you seem to like to maintain newly introduced multimedia libraries in lib32 that have no use case whatsoever. You also tend to cling to extremely old, deprecated, discontinued software that have no users on AUR apart from you.
Deleting lib32-gd of course will allow the deletion of lib32-libheif, a package you maintain in vain, because that also falls into the category of "too new, so no imaginable practical use cases at all in lib32".
Please try, really try to refrain from coming up with moot arguments. Such things do not contribute anything useful to deciding the fate of packages, and the attitude behind it is also detrimental to the community as a whole.
On 30 October 2023 01:35:05 GMT+01:00, sL1pKn07 SpinFlo < sl1pkn07@gmail.com> wrote:
There is no other part of the libgphoto2 code that links to gd.
that statement is not true at all
https://github.com/search?q=repo%3Agphoto%2Flibgphoto2%20gd&type=code
https://github.com/gphoto/libgphoto2/blob/807d44d0dcb0a8a8df151baa27830127fb...
i think you need talk with upstream for why still keep this type of thing in the code if is not used
greetings
El dom, 29 oct 2023 a las 22:55, <notify@aur.archlinux.org> escribió:
MarsSeed [1] filed a deletion request for lib32-gd [2]:
lib32-gd is absolutely unnecessary for lib32-libgphoto2.
The latter could only use gd for on-the-fly image conversion two specific digital "picture frame" hardware, for which libgphoto2 introduced support in 2015, well within the 64-bit era. Also that library is utilized for Docupen scanner pen support, starting from 2020.
There is no other part of the libgphoto2 code that links to gd. Therefore I cannot conceive any application that is bin32 only and needs this specialized functionality of libgphoto2 for those 2015 and 2020 released, 64-bit compatible niche hardware devices.
I've notified the maintainer of lib32-libgphoto2 about this in July 2023.
Deleting this unneeded library would in turn allow other lib32 packages to be dropped. And also it would help reduce the dependency build burden on people who use AUR/wine-stable.
[1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/lib32-gd/
no problem, the package can live in my own :), like always
greetings
I disagree with the deletion request for this package. This software is still receiving updates, as you will see from their git repo https://github.com/libgd/libgd/commits/master/ This PKGBUILD contains no mention of "lib32-libgphoto2" whatsoever, as we see at: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lib32-gd It appears the package maintainer for lib32-libgphoto2 received your feedback and removed the lib32-gd dependency for their package, as seen here: https://aur.archlinux.org/cgit/aur.git/diff/?h=lib32-libgphoto2 Just because you are not using this package anymore MarsSeed does not mean that others are not still using it. Please remove this deletion request. On Sunday, October 29th, 2023 at 5:55 PM, notify@aur.archlinux.org <notify@aur.archlinux.org> wrote:
MarsSeed [1] filed a deletion request for lib32-gd [2]:
lib32-gd is absolutely unnecessary for lib32-libgphoto2.
The latter could only use gd for on-the-fly image conversion two specific digital "picture frame" hardware, for which libgphoto2 introduced support in 2015, well within the 64-bit era. Also that library is utilized for Docupen scanner pen support, starting from 2020.
There is no other part of the libgphoto2 code that links to gd. Therefore I cannot conceive any application that is bin32 only and needs this specialized functionality of libgphoto2 for those 2015 and 2020 released, 64-bit compatible niche hardware devices.
I've notified the maintainer of lib32-libgphoto2 about this in July 2023.
Deleting this unneeded library would in turn allow other lib32 packages to be dropped. And also it would help reduce the dependency build burden on people who use AUR/wine-stable.
[1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/lib32-gd/
MarsSeed [1] filed a deletion request for lib32-gd [2]:
lib32-gd is absolutely unnecessary for lib32-libgphoto2.
The latter could only use gd for on-the-fly image conversion two specific digital "picture frame" hardware, for which libgphoto2 introduced support in 2015, well within the 64-bit era. Also that library is utilized for Docupen scanner pen support, starting from 2020.
There is no other part of the libgphoto2 code that links to gd. Therefore I cannot conceive any application that is bin32 only and needs this specialized functionality of libgphoto2 for those 2015 and 2020 released, 64-bit compatible niche hardware devices.
I've notified the maintainer of lib32-libgphoto2 about this in July 2023.
Deleting this unneeded library would in turn allow other lib32 packages to be dropped. And also it would help reduce the dependency build burden on people who use AUR/wine-stable.
[1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/lib32-gd/
I disagree with the deletion request for this package.
This software is still receiving updates, as you will see from their git repo https://github.com/libgd/libgd/commits/master/
This PKGBUILD contains no mention of "lib32-libgphoto2" whatsoever, as we see at: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lib32-gd
It appears the package maintainer for lib32-libgphoto2 received your feedback and removed the lib32-gd dependency for their package, as seen here: https://aur.archlinux.org/cgit/aur.git/diff/?h=lib32-libgphoto2
Just because you are not using this package anymore MarsSeed does not mean that others are not still using it. Please remove this deletion request.
Despite @jahway603's protest, they haven't done a single step to fix the unbuildable dependency chain which is broken in several packages at the bottom level. Affected are 10 or so AUR packages, none of which have any viable use case in lib32 at all, and never even had. Also failure to understand technical reasoning about the lack of code paths in lib32-libgphoto2 that would ever have had relevance to any consuming application should not be a good enough reason to keep this long defunct and useless and unused package. And it doesn't render my points any less valid and factual.
On Sat, 23 Mar 2024 16:02:40 +0100 Marcell Meszaros <marcell.meszaros@runbox.eu> wrote:
Affected are 10 or so AUR packages, none of which have any viable use case in lib32 at all, and never even had.
Really? So you can guarantee that nobody could be using these libraries for any local project? It doesn't matter in the least that no AUR package depends on it.
Marcell Meszaros <marcell.meszaros@runbox.eu> wrote:
Affected are 10 or so AUR packages, none of which have any viable use case in lib32 at all, and never even had.
Really? So you can guarantee that nobody could be using these libraries for any local project? It doesn't matter in the least that no AUR package depends on it.
Nobody pushed for getting fixes in this dependency chain for the last 2 years. AV1 and HEIF etc formats were introduced a decade and a half after Microsoft forced practically all PC OEM's of the world to transition to x86_64. There are no native libraries and applications that need such in lib32. And if a dependency chain for such a nonexistent use case is rotting for years on AUR, that's pretty much all the evidence one needs to prove total lack of demand. Just because Arch repo's x86_64 multimedia library chain got slavisly recreated on AUR in lib32 without a thought whether there is any point at all, it doesn't mean these packages are legitimate and needed entities. Basically these were pushed to AUR due to lack of understanding and due diligence in this matter. I hope this clarifies my line of thinking. Cheers, Marcell (MarsSeed)
On Sat, 23 Mar 2024 16:34:28 +0100 Marcell Meszaros <marcell.meszaros@runbox.eu> wrote:
Marcell Meszaros <marcell.meszaros@runbox.eu> wrote:
Affected are 10 or so AUR packages, none of which have any viable use case in lib32 at all, and never even had.
Really? So you can guarantee that nobody could be using these libraries for any local project? It doesn't matter in the least that no AUR package depends on it.
Nobody pushed for getting fixes in this dependency chain for the last 2 years.
AV1 and HEIF etc formats were introduced a decade and a half after Microsoft forced practically all PC OEM's of the world to transition to x86_64. There are no native libraries and applications that need such in lib32.
And if a dependency chain for such a nonexistent use case is rotting for years on AUR, that's pretty much all the evidence one needs to prove total lack of demand.
Just because Arch repo's x86_64 multimedia library chain got slavisly recreated on AUR in lib32 without a thought whether there is any point at all, it doesn't mean these packages are legitimate and needed entities.
Basically these were pushed to AUR due to lack of understanding and due diligence in this matter.
I hope this clarifies my line of thinking.
Cheers, Marcell (MarsSeed)
Yes, your line of thinking is that if you're not aware of any usecase, it should be disallowed. Things don't work that way. I really don't know why you insist on picking fights with people, if they want to maintain it, that's up to them. If they're orphans, whatever, but just stop with all of the extra crap.
On 23 March 2024 16:50:53 GMT+01:00, Doug Newgard <dnewgard@outlook.com> wrote:
On Sat, 23 Mar 2024 16:34:28 +0100 Marcell Meszaros <marcell.meszaros@runbox.eu> wrote:
Marcell Meszaros <marcell.meszaros@runbox.eu> wrote:
Affected are 10 or so AUR packages, none of which have any viable use case in lib32 at all, and never even had.
Really? So you can guarantee that nobody could be using these libraries for any local project? It doesn't matter in the least that no AUR package depends on it.
Nobody pushed for getting fixes in this dependency chain for the last 2 years.
AV1 and HEIF etc formats were introduced a decade and a half after Microsoft forced practically all PC OEM's of the world to transition to x86_64. There are no native libraries and applications that need such in lib32.
And if a dependency chain for such a nonexistent use case is rotting for years on AUR, that's pretty much all the evidence one needs to prove total lack of demand.
Just because Arch repo's x86_64 multimedia library chain got slavisly recreated on AUR in lib32 without a thought whether there is any point at all, it doesn't mean these packages are legitimate and needed entities.
Basically these were pushed to AUR due to lack of understanding and due diligence in this matter.
I hope this clarifies my line of thinking.
Cheers, Marcell (MarsSeed)
Yes, your line of thinking is that if you're not aware of any usecase, it should be disallowed. Things don't work that way. I really don't know why you insist on picking fights with people, if they want to maintain it, that's up to them. If they're orphans, whatever, but just stop with all of the extra crap.
I'm not picking any fights. The package was an orphan 5 months ago when I filed my deletion request. Then @jahway603 adopted it and didn't do anything to make its dependency chain buildable, but he immediately wrote a very hostile but otherwise ignorant and clueless response to the ML. Please get your facts straight before unfairly blaming me. Instead, please refute my arguments point by point if you can, or stay away from pointless waste of each other's time and attention. AUR submission guidelines don't say any package can be kept on it if it has an owner. It says packages here should be useful to more than just a few people. I think I have demonstrated beyond reasonable doubt that this dependency chain does not qualify as legit AUR entities. While you have failed to come up with any evidence to the contrary. So this leads to the logical conclusion that it is you who is picking a fight, not me. Please continue only in a constructive manner. Btw if packages gets deleted fron AUR, their repos still stay on the git server. At any point in the future any user can recreate them. So if AUR will exist in a 10 or 20 years from now and some human or alien wants to put back some historic lib32 package that no one ever used, they will be able to revive it. XD
El sáb, 23 mar 2024 a las 17:12, Marcell Meszaros (< marcell.meszaros@runbox.eu>) escribió:
On Sat, 23 Mar 2024 16:34:28 +0100 Marcell Meszaros <marcell.meszaros@runbox.eu> wrote:
Marcell Meszaros <marcell.meszaros@runbox.eu> wrote:
Affected are 10 or so AUR packages, none of which have any viable use case in lib32 at all, and never even had.
Really? So you can guarantee that nobody could be using these
On 23 March 2024 16:50:53 GMT+01:00, Doug Newgard <dnewgard@outlook.com> wrote: libraries for
any local project? It doesn't matter in the least that no AUR package depends on it.
Nobody pushed for getting fixes in this dependency chain for the last 2 years.
AV1 and HEIF etc formats were introduced a decade and a half after Microsoft forced practically all PC OEM's of the world to transition to x86_64. There are no native libraries and applications that need such in lib32.
And if a dependency chain for such a nonexistent use case is rotting for years on AUR, that's pretty much all the evidence one needs to prove total lack of demand.
Just because Arch repo's x86_64 multimedia library chain got slavisly recreated on AUR in lib32 without a thought whether there is any point at all, it doesn't mean these packages are legitimate and needed entities.
Basically these were pushed to AUR due to lack of understanding and due diligence in this matter.
I hope this clarifies my line of thinking.
Cheers, Marcell (MarsSeed)
Yes, your line of thinking is that if you're not aware of any usecase, it should be disallowed. Things don't work that way. I really don't know why you insist on picking fights with people, if they want to maintain it, that's up to them. If they're orphans, whatever, but just stop with all of the extra crap.
I'm not picking any fights.
The package was an orphan 5 months ago when I filed my deletion request. Then @jahway603 adopted it and didn't do anything to make its dependency chain buildable, but he immediately wrote a very hostile but otherwise ignorant and clueless response to the ML. Please get your facts straight before unfairly blaming me.
Instead, please refute my arguments point by point if you can, or stay away from pointless waste of each other's time and attention.
AUR submission guidelines don't say any package can be kept on it if it has an owner. It says packages here should be useful to more than just a few people. I think I have demonstrated beyond reasonable doubt that this dependency chain does not qualify as legit AUR entities. While you have failed to come up with any evidence to the contrary.
So this leads to the logical conclusion that it is you who is picking a fight, not me.
Please continue only in a constructive manner.
Btw if packages gets deleted fron AUR, their repos still stay on the git server. At any point in the future any user can recreate them. So if AUR will exist in a 10 or 20 years from now and some human or alien wants to put back some historic lib32 package that no one ever used, they will be able to revive it. XD
constructive manner? my constructive manner: i'm not trust you as TU, please leave that role i need remember you are the only TU has been moderated in two times greetings
Request #49836 has been Rejected by muflone [1]: no reason to delete it, also if it's actually not required by others packages [1] https://aur.archlinux.org/account/muflone/
participants (5)
-
Doug Newgard
-
jahway603
-
Marcell Meszaros
-
notify＠aur.archlinux.org
-
sL1pKn07 SpinFlo