Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: autogen - Automated text file generator https://bugzilla.redhat.com/show_bug.cgi?id=432542 mtasaka@xxxxxxxxxxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|433199 | nThis| | ------- Additional Comments From mtasaka@xxxxxxxxxxxxxxxxxxx 2008-02-17 11:11 EST ------- (In reply to comment #6) > Strangely the latest libopts tarball from upstream is versioned 27.6: > http://gnu.glug-nith.org/libopts/rel27.6/ > > At the same time, Debian ships a libopts package that bears the same EVRA as > autogen: http://packages.debian.org/experimental/libopts25 I took this option. > Remember due to the multiple licensing scenario we have to separate the libopts > (or autoopts) portion from the rest of autogen. > > What do you suggest? This is *only my opinion* I think that if you want to name the libopts related subrpm as "libopts" the version should be 31.0.6 (as autoopts-config --version surely returns this value) texlive maintainers use this method (i.e. they allow different versions for subpackage), however I really don't want this. _IMO_ it is better that libopts related packages are named to show explicitly that they are subpackages of autogen, i.e. they should be autogen-libopts-devel, for example (as we actually did so in tetex age) with the same EVR as autogen main package. (In reply to comment #7) > It looks to me that the *.autogen suffix is not required because no other > package seems to provide binaries of the same name. If that is so, we can drop > the dependency on %{_sbindir}/alternatives. If you don't know why alternatives is used here (note that I don't know either) it should just be dropped. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review