there are at least 3 packaging issues with recent sdcc package - emacs support files should go into emacs-sdcc subpackage (https://fedoraproject.org/wiki/Packaging/Emacs#Other_packages_containing_Emacsen_add-ons and https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28emacs_components.29) - some docs are present in both pdf and plaintext and they are quite large, maybe a sdcc-docs subpackage will be more appropriate - something is wrong with handling of CFLAGS, I see 4 or even 6 copies of the CFLAGS on the gcc command line during the build phase when compiling in the src directory If I will find some spare time, I will look at them.
I'll be able to take a look at this in a couple hours. Thanks for reporting a bug!
(In reply to comment #0) > there are at least 3 packaging issues with recent sdcc package > - emacs support files should go into emacs-sdcc subpackage > (https://fedoraproject.org/wiki/Packaging/Emacs#Other_packages_containing_Emacsen_add-ons > and > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28emacs_components.29) There are 2 emacs .el scripts, and they're 80 kilobytes total. Do they really need a separate package? I'm not an emacs user; maybe adding a Provides: emacs-sdcc = %{version}-%{release} to the main rpm would satisfy this? > - some docs are present in both pdf and plaintext and they are quite large, > maybe a sdcc-docs subpackage will be more appropriate %{_datadir}/doc/sdcc-2.8.0/ only comes out to 4 megabytes with 'du -sh', which isn't unreasonable IMO. Is there some motivation for me to split out a -docs subpackage (guideline or something)? > - something is wrong with handling of CFLAGS, I see 4 or even 6 copies of the > CFLAGS on the gcc command line during the build phase when compiling in the src > directory What's wrong with that? GCC ignores anything but the last of a given flag passed to it.
(In reply to comment #2) > (In reply to comment #0) > > there are at least 3 packaging issues with recent sdcc package > > - emacs support files should go into emacs-sdcc subpackage > > (https://fedoraproject.org/wiki/Packaging/Emacs#Other_packages_containing_Emacsen_add-ons > > and > > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28emacs_components.29) > > There are 2 emacs .el scripts, and they're 80 kilobytes total. Do they really > need a separate package? I'm not an emacs user; maybe adding a Provides: > emacs-sdcc = %{version}-%{release} to the main rpm would satisfy this? > The main problem here is that sdcc owns the %{datadir}/emacs directory and that's bad (emacs should be the only owner). So you could package only the *.el files with %{datadir}/emacs/site-lisp/*.el, but the you must Require: emacs for proper handling of the %{datadir}/emacs/site-lisp/ directory. So the only correct solution is to put the *.el files into its own subpackage that will conform to the emacs guidelines. > > - some docs are present in both pdf and plaintext and they are quite large, > > maybe a sdcc-docs subpackage will be more appropriate > > %{_datadir}/doc/sdcc-2.8.0/ only comes out to 4 megabytes with 'du -sh', which > isn't unreasonable IMO. Is there some motivation for me to split out a -docs > subpackage (guideline or something)? The review guideline says that large docs should go into docs subpackage, but the size of "large" is defined by a consensus between maintainer and reviewer. So I am accepting your opinion :-) > > > - something is wrong with handling of CFLAGS, I see 4 or even 6 copies of the > > CFLAGS on the gcc command line during the build phase when compiling in the src > > directory > > What's wrong with that? GCC ignores anything but the last of a given flag > passed to it. Yes, it compiles correctly, but orientation is hard in the created mess (really easy to oversee a -O0 after six occurrences of -O2). And it's probably a symptom of a buggy upstream buildsystem.
(In reply to comment #3) > (In reply to comment #2) > > There are 2 emacs .el scripts, and they're 80 kilobytes total. Do they really > > need a separate package? I'm not an emacs user; maybe adding a Provides: > > emacs-sdcc = %{version}-%{release} to the main rpm would satisfy this? > > > > The main problem here is that sdcc owns the %{datadir}/emacs directory and > that's bad (emacs should be the only owner). So you could package only the *.el > files with %{datadir}/emacs/site-lisp/*.el, but the you must Require: emacs for > proper handling of the %{datadir}/emacs/site-lisp/ directory. So the only > correct solution is to put the *.el files into its own subpackage that will > conform to the emacs guidelines. That makes sense to me. Will fix. > The review guideline says that large docs should go into docs subpackage, but > the size of "large" is defined by a consensus between maintainer and reviewer. > So I am accepting your opinion :-) Well, there are 4 megs of extracted docs and the entire RPM is 3.5 megs. Granted, that's compressed, and still not very large, but docs are (probably) a large portion of that. > > What's wrong with that? GCC ignores anything but the last of a given flag > > passed to it. > > Yes, it compiles correctly, but orientation is hard in the created mess (really > easy to oversee a -O0 after six occurrences of -O2). And it's probably a > symptom of a buggy upstream buildsystem. Probably true but I'm not responsible for fixing upstream's buildsystem (and in fact, I've been told off for doing so in the past :D).
http://koji.fedoraproject.org/koji/taskinfo?taskID=932450 <-- That addresses the emacs concerns, I believe. Is it ok for you?
(In reply to comment #5) > http://koji.fedoraproject.org/koji/taskinfo?taskID=932450 <-- That addresses > the emacs concerns, I believe. Is it ok for you? Yes, it is, thanks.
Alright I'll close it now and build & push updates for F-10 and F-9 updates-testing later this weekend when I get a chance.
> > > What's wrong with that? GCC ignores anything but the last of a given flag > > > passed to it. > > > > Yes, it compiles correctly, but orientation is hard in the created mess (really > > easy to oversee a -O0 after six occurrences of -O2). And it's probably a > > symptom of a buggy upstream buildsystem. > > Probably true but I'm not responsible for fixing upstream's buildsystem (and in > fact, I've been told off for doing so in the past :D). Yes, but some maintainers try to fix even such upstream issues and report them together with patches, so there is higher chance it will be fixed in the next upstream release.