[pacman-dev] [PATCH] RFC: remove upx and optipng support from makepkg
These options were added before libmakepkg allowed passes like this to be
dropped in. I prefer only real core packaging tasks to be included in
makepkg and additional things like this to be dropped in by a user or
distribution that wants to support them.
Signed-off-by: Allan McRae
On 02.02.2016 02:44, Allan McRae wrote:
These options were added before libmakepkg allowed passes like this to be dropped in. I prefer only real core packaging tasks to be included in makepkg and additional things like this to be dropped in by a user or distribution that wants to support them.
The linux folks want as many modules in their tree as possible so that they can improve/change the interfaces between the core and the modules easily and without breaking third-party modules. I also have the feeling that any time I see software supporting plugins, these plugins are more often than not in bad shape, especially when they are maintained by a third party. These two modules seem to be really small and should not require much maintenance. Considering the points mentioned above I'd suggest to keep them. Florian
On 03/02/16 00:18, Florian Pritz wrote:
On 02.02.2016 02:44, Allan McRae wrote:
These options were added before libmakepkg allowed passes like this to be dropped in. I prefer only real core packaging tasks to be included in makepkg and additional things like this to be dropped in by a user or distribution that wants to support them.
The linux folks want as many modules in their tree as possible so that they can improve/change the interfaces between the core and the modules easily and without breaking third-party modules. I also have the feeling that any time I see software supporting plugins, these plugins are more often than not in bad shape, especially when they are maintained by a third party.
Linux wants to make sure everything boots and functions out of the box. I don't want to make makepkg achieve every possible packaging pass. I have already rejected a request to add SVG optimization (and something else I can not remember...).
These two modules seem to be really small and should not require much maintenance. Considering the points mentioned above I'd suggest to keep them.
I consider these modules unmaintained - I will not fix any bug in them (e.g. we can not use either with a clean chroot) and no-one else really works on makepkg... A
On 03/02/16 07:51, Allan McRae wrote:
On 03/02/16 00:18, Florian Pritz wrote:
On 02.02.2016 02:44, Allan McRae wrote:
These options were added before libmakepkg allowed passes like this to be dropped in. I prefer only real core packaging tasks to be included in makepkg and additional things like this to be dropped in by a user or distribution that wants to support them.
The linux folks want as many modules in their tree as possible so that they can improve/change the interfaces between the core and the modules easily and without breaking third-party modules. I also have the feeling that any time I see software supporting plugins, these plugins are more often than not in bad shape, especially when they are maintained by a third party.
Linux wants to make sure everything boots and functions out of the box. I don't want to make makepkg achieve every possible packaging pass. I have already rejected a request to add SVG optimization (and something else I can not remember...).
These two modules seem to be really small and should not require much maintenance. Considering the points mentioned above I'd suggest to keep them.
I consider these modules unmaintained - I will not fix any bug in them (e.g. we can not use either with a clean chroot) and no-one else really works on makepkg...
Was there any other opinion on these? Allan
On Fri, 12 Feb 2016 21:15:24 +1000, Allan McRae
On 03/02/16 07:51, Allan McRae wrote:
On 03/02/16 00:18, Florian Pritz wrote:
On 02.02.2016 02:44, Allan McRae wrote:
These options were added before libmakepkg allowed passes like this to be dropped in. I prefer only real core packaging tasks to be included in makepkg and additional things like this to be dropped in by a user or distribution that wants to support them.
The linux folks want as many modules in their tree as possible so that they can improve/change the interfaces between the core and the modules easily and without breaking third-party modules. I also have the feeling that any time I see software supporting plugins, these plugins are more often than not in bad shape, especially when they are maintained by a third party.
Linux wants to make sure everything boots and functions out of the box. I don't want to make makepkg achieve every possible packaging pass. I have already rejected a request to add SVG optimization (and something else I can not remember...).
These two modules seem to be really small and should not require much maintenance. Considering the points mentioned above I'd suggest to keep them.
I consider these modules unmaintained - I will not fix any bug in them (e.g. we can not use either with a clean chroot) and no-one else really works on makepkg...
Was there any other opinion on these?
Allan
I'll throw in my 2 cents. I agree that it's not worth trying to optimize the package in every way possible. If the packager or the user really cares about space that much then they'll do the compressing themselves. Thinking on it as more of a packager, I've only ever noticed upx when it's been a problem. Space is so cheap that I'm willing to give a tiny bit of it up if it means that I don't have to deal with worrying about whether or not the option is going to cause problems on other people's machines. So yes they are tiny modules but if we aren't really going to support them and they aren't providing much benefit then I say remove them. With respect to the patch, we'll need to remove those options from the PKGBUILD man page as well. A quick "grep -r" shows upx in makepkg.conf and it's man page also, as well as in makepkg.sh.in. Ashley
Allan McRae
BAH! I reluctently accepted the optipng patch before I split out libmakepkg. I never thought of removing it before it saw a release...
*sigh* It was me who added the optipng thing. In fact my primary thought was not about saving space - that's only some kB for each package, if at all. When I added this we had early libpng releases with had problems with ancient broken png files that are still around in some packages. Using optipng was an easy way to fix this. Space saving was just an extra. ;) So if you think this is a burden to maintain just remove it... I am pretty sure I can live without. (Anyway... Did not see bad impact of broken png files in a long time now.) -- Best regards, Chris
On 12/02/16 20:09, Christian Hesse wrote:
When I added this we had early libpng releases with had problems with ancient broken png files that are still around in some packages. Using optipng was an easy way to fix this. Space saving was just an extra. ;) Recently, there was a bug affecting an SVG library in a similar way. [1] Until it was fixed, I solved this problem manually converting the image in the PKGBUILD. The SVG optimization Allan mentioned could possibly have been an easy fix. So I think of them as useful. However, keeping the modules in the main pacman repository with no real maintenance also gives the wrong impression.
Throwing away both altogether seems to me like discarding sensible work already done. As far as I understand the structure, they could simply be moved out to another package. PKGBUILDs using the respective options could then simply depend on this package. So how about posting them to the AUR as "makepkg-optimize", orphaned. This would leave the content in a usable state, while clearly showing that it is unsupported and without maintainer. From there, any interested developer still using those options may even take over. [1]: https://bugs.archlinux.org/task/47245
participants (5)
-
Allan McRae
-
Ashley Whetter
-
Christian Hesse
-
Dominik Fischer
-
Florian Pritz