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
