On Sun, 2008-01-27 at 03:18 +0000, Kevin Kofler wrote: > Horst H. von Brand <vonbrand <at> inf.utfsm.cl> writes: > > > Well, your arguments are pretty unconvincing, and apply to a lot of > > > application-library relationships, still usually library users won't fork a > > > library just for that, or when they do, Fedora won't ship their fork. > > > > AFAIU this is an /upstream/ decision, not a Fedora one. > > It is an upstream decision to ship that fuse-lite fork in the tarball and to > support it. It is a Fedora decision to actually use this fork rather than > using --with-fuse=external. (In many cases, we even _patch_ upstream projects > to use system libraries where they don't support it at all, in this case, it > would just be a configure option.) I'm complaining about both. The ntfs-3g spec file is currently conditionalized to use fuse-lite by default, because: A) I'm concerned that future ntfs-3g specific functionality in fuse-lite won't go into FUSE. B) The upstream FUSE lead developer thinks that fuse-lite is a good idea in ntfs-3g. C) I'm comaintaining FUSE in Fedora, so I should be able to handle any security issues that might need to be doublechecked. With that said, I'm not entirely convinced that fuse-lite is the right decision. I might change my mind, and make the default be --with-fuse=external, but it will be still conditionalized so that the SRPM can be easily rebuilt to the opposite. ~spot -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
