Bug 471376 - packaging issues
packaging issues
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: sdcc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Conrad Meyer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-13 06:26 EST by Dan Horák
Modified: 2008-11-14 04:51 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-14 04:48:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Horák 2008-11-13 06:26:12 EST
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.
Comment 1 Conrad Meyer 2008-11-13 11:43:53 EST
I'll be able to take a look at this in a couple hours. Thanks for reporting a bug!
Comment 2 Conrad Meyer 2008-11-13 14:39:41 EST
(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.
Comment 3 Dan Horák 2008-11-13 16:46:26 EST
(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.
Comment 4 Conrad Meyer 2008-11-13 16:58:44 EST
(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).
Comment 5 Conrad Meyer 2008-11-13 18:02:07 EST
http://koji.fedoraproject.org/koji/taskinfo?taskID=932450 <-- That addresses the emacs concerns, I believe. Is it ok for you?
Comment 6 Dan Horák 2008-11-14 04:43:29 EST
(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.
Comment 7 Conrad Meyer 2008-11-14 04:48:34 EST
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.
Comment 8 Dan Horák 2008-11-14 04:51:51 EST
> > > 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.

Note You need to log in before you can comment on or make changes to this bug.