On Mon, 31 Aug 2015, Bas Wijnen wrote:
> > I certainly do not want to move wordpress or publican to contrib because
> In that case, my question applies to you as well: why do you care for it to be
> in main, if you are unwilling to follow the rules we have set up for it?
> > are free software
> Which require a compiler that is not in main to build. That is the definition
> of what contrib is for. Why shouldn't it go in there?
Because we have alternative "compilers" (aka minifier) available to
recreate another minified file thas should work just as well.
product, they are external libraries whose preferred form of use is
by embedding a copy of the library... that sucks but it's the way it is.
I do not see significant value in extending my packaging to rebuild
the minified files from source as part of the wordpress/publican source
package. On the opposite, it has a significant cost:
- I have to add the sources when upstream does not ship them
(which is not a problem for many upstreams since the BSD-ish
licences do not require you to provide the sources)
- ensure the sources are in sync with the minified copy
(even when friendly upsreams provide the required sources
on our request, they sometimes updates only one the minified file
and forget about the sources in some other directory)
- if the minifier is not the same as upstream, it will create
a divergence with upstream and can always be a source of
suspicion when we report issues to upstream...
libraries embedded in wordpress/publican, they can grab the source package
of the corresponding libraries, do their changes and build modified
libraries there. After that they can update it in the publican/wordpress
package by replacing the embedded copy.
> Are you arguing that having tools to go from source to binary available in main
> should not be a requirement for a package to be in main?
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/