Bug 471376

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.