[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Bug 179802] Review Request: seamonkey



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: seamonkey


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179802





------- Additional Comments From caillon redhat com  2006-02-10 15:21 EST -------
(In reply to comment #4)
> > - Don't BuildRequire autoconf213; if you make changes to configure, include that
> > part in the patch
> 
> I think that request makes package maintenance a bit inconvenient,
> but you probably have a good reason to suggest that.
> removed

Mozilla's build inadequacies is their problem.  The only reason we have this
package at all is because mozilla still needs it to generate configure.  There's
no need to force this requirement on people who simply want to build an SRPM.


 
> > - You probably ought to have the FindExternalProvides stuff that the Firefox and
> > Thunderbird package does.  Since the libraries provided aren't versioned, this
> > can cause problems when two packages provide the same libraries (mozilla also
> > provides these for now, and when xulrunner eventually takes over, it will do
so).
> 
> I'm confused, because you mention FindExternal and Provides in one word,
> but I can't find such a thing in the TB and FF spec files.
> Are you suggesting to add the following 3 lines?
>   AutoProv: 0
>   %define _use_internal_dependency_generator 0
>   %define __find_requires %{SOURCE100}
> That's what I did.
> 
> But I ended up with a depency problem, although package "seamonkey" contained
> libxpcom_core.so, package "seamonkey-mail" complained that lib can't be found.
> Therefore I set AutoProv to on, that made it work, but we again have 
> lots of provides. Is that ok, or do you suggest a different way to fix it?

Does it work if you Require: seamonkey (it should be Require anyway, and please
one Require per line.)



> > - Use a .mozconfig file (see what I do in the firefox package).  This will make
> > it easier to do development with the same flags with a different tree (just copy
> > the mozconfig over)
> 
> Ok, done. Motivated by your proposal, I tried to 
> use the same build code as used in the firefox spec file.
> But that failed, I got errors in install stage,

What specific errors?



> The mozilla 1.7.x package does the same thing!

Yeah, its a bug that we need to fix there, too.  Don't copy over bugs :-)

> The statement currently in use is %defattr(-,root,root).
> I think we must not chance the modes for most of the files,
> so your request means, we'd have to filter the *.js files
> from the "list of files" and use explicit %defattr(644) statements for them.
> Do you want me to hack "sed/grep" code to change the file lists?
> Or should we use some "find" statements to change the modes before they 
> are copied? Or do you have a better idea?

I think either solution is probably sufficient.  Will look at the rest over the
weekend.


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]