Fix dependentlibs.list packaging in SeaMonkey

RESOLVED FIXED in seamonkey2.1a1

Status

SeaMonkey
Build Config
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: sgautherie, Assigned: sgautherie)

Tracking

Trunk
seamonkey2.1a1
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by bug 521523])

(Assignee)

Description

8 years ago
http://mxr.mozilla.org/mozilla/search?string=dependentlibs.list&case=on
http://mxr.mozilla.org/mozilla1.9.1/search?string=dependentlibs.list&case=on
(I would have to check if FF 3.0/3.5 actually packaged this file or not...)

http://mxr.mozilla.org/mozilla1.9.2/search?string=dependentlibs.list&case=on
http://mxr.mozilla.org/comm-central/search?string=dependentlibs.list&case=on
FF 3.6+ seems to want to remove it only.

Yet SeaMonkey 2.0/2.1 reports:
{
'make package-compare'
[...]
+bin/dependentlibs.list
}

Then I'm puzzled at what the correct fix would be:
*Should SM package the available file??
*Should SM (or Core) not create this file in the first place!?
*...
Flags: in-testsuite-
(Assignee)

Updated

7 years ago
Depends on: 542004

Comment 1

7 years ago
I have this incorporated into my patch for bug 521523 at the moment.

I don't see what you mean with "FF 3.6 seems to want to remove it only", in fact I see it being packaged in http://mxr.mozilla.org/comm-central/source/mozilla/browser/installer/package-manifest.in#43
Depends on: 521523

Comment 2

7 years ago
Should be fixed by bug 521523 now.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Keywords: helpwanted
Resolution: --- → FIXED
(Assignee)

Comment 3

7 years ago
(In reply to comment #1)

> I have this incorporated into my patch for bug 521523 at the moment.

Indeed.
c-c: fixed.
c-c wrt m-1.9.2: fixed, ahead of FF3.6.
c-1.9.1: probably still needs fixing (here)...

> I don't see what you mean with "FF 3.6 seems to want to remove it only",

I understand your comment: see bug 542004 which landed in the meantime(!) ;->

Per discussion there, shouldn't SM use an "#ifdef MOZ_LIBXUL" or the like?
(even if that means getting this file back in the report ftb :-/)
And we should probably remove this file when "#ifndef MOZ_LIBXUL" too, no?
Whiteboard: [fixed by bug 521523]

Comment 4

7 years ago
(In reply to comment #3)
> I understand your comment: see bug 542004 which landed in the meantime(!) ;->
> 
> Per discussion there, shouldn't SM use an "#ifdef MOZ_LIBXUL" or the like?

We should test carefully and see if there are problems with having this file in our builds even though we're not libxul-based. If there actually is no problem, we can just leave it as-is.
You need to log in before you can comment on or make changes to this bug.