[FFmpeg-devel] libraries linked with libX11 on GNU/kFreeBSD
Fri Jul 18 00:56:17 CEST 2008
On Thu, Jul 17, 2008 at 12:46:47PM +0200, Reinhard Tartler wrote:
> Diego Biurrun <diego at biurrun.de> writes:
> > On Thu, Jul 17, 2008 at 07:59:46AM +0200, Reinhard Tartler wrote:
> >> M?ns Rullg?rd <mans at mansr.com> writes:
> >> >> Anyway, patch looks OK to me, cleaning up LDLATEFLAGS is outside of the
> >> >> scope of adding gnu/kfreebsd support.
> >> >
> >> > I stand by my rejection of the patch. The existing code is wrong. We
> >> > should fix it properly instead of adding more broken code.
> >> Okay, no problem. I'll carry then this patch in the debian/ubuntu
> >> package until the code in question gets replaced upstream then. And to
> >> be honest, I doubt that someone outside Debian actually cares about
> >> gnu/kfreebsd.
> > An even better procedure would be to propose the patch before applying
> > it to your package and then try to find a clean solution in cooperation
> > with your upstream (us). You could then backport such a solution to
> > your package.
> Yes, I agree that this is a good idea to do in general. However for
> this particular issue, this particular patch is pretty trivial and does
> affect only a very small number of machines. Here, it affects only
> gnu/kfreebsd machines. For more complicated patches, I'd of course
> prefer to have it commented by some more experienced developer before
> publishing it anywhere.
The patch seemed trivial, but it was still an ugly workaround for a
different issue. I committed a proper fix in less than 24 hours. How
much quicker do you want us to react? Now you have to revert your patch
and backport mine - twice the work...
> Btw, you might have noticed that nowadays all patches in the
> ffmpeg-debian package have descriptive comments why they have been
> applied and where they originate. This makes it easier to eventually get
> rid of them.
Yes, that is good. As I said, the package is in much much better shape
since you took over and accepted the help of myself and other to improve
> > Still, this reminds me a bit of a "shoot first, ask questions later"
> > attitude ;) - in a perfect world you would choose the first route
> > instead of the second.
> Uhm, I it's not that this couldn't be easily reverted. Generally I think
> first committing it the package branch for building test packages is not
> something unreasonable to do. If the patch gets commented on later on
> this mailing list, it can still be improved before publishing a package
> in debian. Having that in mind, I don't think the analogy "shoot first,
> ask questions later" really applies here.
Note the smiley.
Still I think you going down the wrong route. Everybody's life will be
better if you pass patches through upstream directly. Just cut out the
middlemen, save everybody time and improve the quality of your package
and upstream FFmpeg.
More information about the ffmpeg-devel