El vie, 24 nov 2023 a las 12:56, Marcell Meszaros (< [email protected]>) 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/807d44d0dcb0a8a8df151baa27830127fbbbbef6/configure.ac#L373-L382 > > 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 < > [email protected]> 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/807d44d0dcb0a8a8df151baa27830127fbbbbef6/configure.ac#L373-L382 >> >> 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, <[email protected]> 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
