Hi, > > Given that autogen is a development package anyway. GCC-from-source > > builders aside, essentially anyone wanting autogen is going to want > > the two files in autogen-devel. Given that and the sub-marginal > > amount of space taken by the two files, I fail to understand why > > it is worth the bother to separate. > > > Please open a bug in bugzilla. The packager of autogen needs to respond > to your comments and that's the only way to be sure to get a hold of > them. If you find the packager to be unreasonable other packagers can > then get involved if there's a clear path forward. As the packager... I have followed the rules regarding the headers being in their own -devel file. The problem (as I see it) is that without the devel package, the main package is pretty useless. However, adding R:autogen-devel causes problems (circular deps) > Is alternatives the right solution to this problem? Probably not. > Alternaties was invented to address things like sendmail's sendmail > program vs postfix's sendmail program. Both those programs take the > same options on the commandline and yield similar results through > different backends. Is autogen's version of /usr/bin/columns part of > POSIX, the Single Unix Specification, or LSB? If so, we have a solid > foundation and alternatives (or removing alternatives as there is no > alternative implementation in the system currently) makes sense. If > not, then we can only hope that no other open source software chooses > the generic /usr/bin/columns name for their program otherwise we all > lose. It is certainly a pain and would appreciate some guidance on either repackaging this or the next step forward. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen!
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
