Here's a patch which allows disabling command line utils, old-style config script, etc at build time. * http://patches.metux.de/audiofile/src/tiny-install.diff Please also have a look at: * http://bugfarm.metux.de/show_bug.cgi?id=98 Probably there's still some packages using the old audiofile.m4 macro instead of th pkg-config database. Please report if you find one.
Created attachment 92716 [details, diff] patch against audiofile-0.2.6 intruduces: --disable-examples --disable-tests --disable-old-pkgconfig --disable-tools
@reporter, the links looks dead, could you update them ? @herds, is it worth a minimal USE ?
> @herds, is it worth a minimal USE ? yes, if we can do it cleanly
Patch looks really good... but : 1) is it worth it? 2) can't we just disable everything instead of having configure switches? 3) upstream looks dead... what do we do about that?
I *reall* think, it's worth it all. Installations should always contain the necessary things - why else do have useflags ? ;-o Maybe a more sophisticated approach would be splitting it into library and utils package (shouldn't be such a hard job). BTW: if upstream's really dead (any verification on that ?), please let me know - the OSS-QM project will take over :) cu
(In reply to comment #5) > I *reall* think, it's worth it all. > Installations should always contain the necessary things - why else do have > useflags ? ;-o True > Maybe a more sophisticated approach would be splitting it into library and > utils package (shouldn't be such a hard job). Thing is, it is tradition in Gentoo to stick to upstream packages as closely as possible. And that's what we do for Gnome packages. I'm not really sure what the Sound Herd's stance on this issue is. If upstream accepts a patch, we'll gladly accept it here too while another release is being made. > BTW: if upstream's really dead (any verification on that ?), please let me know I don't know for sure, I just saw the last release is _four_ years old and the BK repo hasn't seen any activity for 4 years either. > - the OSS-QM project will take over :) Don't know that project. Probably best to get in touch with the original author first. There are already a few commits in BK that might not be in the latest tarball. Your patch looks good, I don't see why the original author would reject it. Thanks
(In reply to comment #6) > Thing is, it is tradition in Gentoo to stick to upstream packages as closely as > possible. And that's what we do for Gnome packages. I'm not really sure what > the Sound Herd's stance on this issue is. That's not always good. Often the upstream (IMHO) does a lot of crap ;-O > > BTW: if upstream's really dead (any verification on that ?), please let me know > > I don't know for sure, I just saw the last release is _four_ years old and the > BK repo hasn't seen any activity for 4 years either. Maybe you could ask them about this ? > > - the OSS-QM project will take over :) > > Don't know that project. http://oss-qm.metux.de/ Main purpose of the project is to provide an kind of "overlay" against the upstream(s). There are lots of patches (virtually against any release) to fix things like fully-automated building, crosscompiling, etc. > Probably best to get in touch with the original author first. > There are already a few commits in BK that might not be in the latest > tarball. Your patch looks good, I don't see why the original author would > reject it. Perhaps you would like to take this job ? :) cu
(In reply to comment #7) > That's not always good. Often the upstream (IMHO) does a lot of crap ;-O I have yet to see any upstream refuse a good patch with sensible arguements. :) > Maybe you could ask them about this ? Hey, you proposed the patch, the way audiofile is handled today is fine by both the Gnome and Sound Herds. > Main purpose of the project is to provide an kind of "overlay" against > the upstream(s). There are lots of patches (virtually against any release) > to fix things like fully-automated building, crosscompiling, etc. We don't really need an overlay of patch, we need alive upstream projects that we can forward bugs and patches to. If you're willing to take over the entire audiofile project, then fine :) > Perhaps you would like to take this job ? :) Again, you proposed the patch ;) that's your job. We've got enough work on our hands as it is. Thanks
(In reply to comment #8) > (In reply to comment #7) > > That's not always good. Often the upstream (IMHO) does a lot of crap ;-O > > I have yet to see any upstream refuse a good patch with sensible arguements. :) Well, I did :( Most times, the upstream's just too slow for getting in patches ASAP (and this often wouldn't fit their policies). Sometimes they just break a lot of things w/o proper forking, and so leave a lot of dirty work to packagers. IMHO, packager's shouldn't have to cope with bugfixing - their job's just to get some package built into their target platform. But reality's often very far from that :( > > Maybe you could ask them about this ? > > Hey, you proposed the patch, the way audiofile is handled today is fine by both > the Gnome and Sound Herds. hmmpf, I hope'd to get the dirty work delegated to someone else ;-o Well, I've sent the patch to the audiofile maintainer - let's see what happens. > > Main purpose of the project is to provide an kind of "overlay" against > > the upstream(s). There are lots of patches (virtually against any release) > > to fix things like fully-automated building, crosscompiling, etc. > > We don't really need an overlay of patch, we need alive upstream projects that > we can forward bugs and patches to. If you're willing to take over the entire > audiofile project, then fine :) Perhaps I should explain the OSS-QM project a bit more detailed: If you (as package maintainer) jump to OSS-QM, this will now be *your* (proxy) upstream. Contrary to most upstreams, OSS-QM has an ASAP release policy: Virtually each bugfix triggers an new release (or maybe collected multiple within a few days). So, once a bug is fixed, you'll always have it in the most recent release. New upstream releases are checked for backwards compatibility - if it fails, the new upstream release won't pass. (OSS-QM will decide whether to fix the break or fork). This way, all you now have to do is keeping up-to-date (from the OSS-QM rep.) Another fine feature: All version numbers are *canonical*, the version space is an simple hierachy of naturals, which is trivial to compare (>=,==,=<). Smaller versions can always be replaced by larger ones. (if this happens to break, there is a major bug). For each (supported) upstream version, there is an complete patch against it, so you can apply it 100% automatically. All OSS-QM patches are strictly distro agnostic. Instead of changing things for some specific distro, they provide proper (build-time) switches for distro- specific configuration. Coupled with the CSDB project (http://sourcefarm.metux.de), individual distros don't even have to care about individual download URLs - just query the CSDB. If, for example, Gentoo would entirely use OSS-QM and CSDB, there were only ebuilds in portage, and they just call the package's build scripts with appropriate parameters (no patching, individual installations, etc). cu
Enrico, did you contact upstream? Thanks
No answer for 3 months... closing. Anyhow, Gentoo's patch policy is very clear : we stay as close as possible to upstream. If upstream is dead, someone forks or the package is treecleaned once issues creep up. Audiofile works as-is and there's no obvious benefit to such a big patch. Thanks
