238359 - Linux installer does not install init.d/ directory

Status: RESOLVED FIXED

(SeaMonkey :: Installer, defect)

Description

[Roland Mainz]

http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7b/mozilla-i686-pc-linux-gnu-1.7b-installer.tar.gz
(Mozilla 1.7b Linux/x86 Full installer) does not install the mozilla/init.d/
directory (and the mozilla/init.d/README directory is missing, too).

Steps to reproduce:
1. Download
http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7b/mozilla-i686-pc-linux-gnu-1.7b-installer.tar.gz
2. Install Mozilla ("default" installation profile)

Result:
No init.d/ directory in the installation

Expected result:
init.d/ and init.d/README should be there...

Comment 1

[Roland Mainz]

I suggest that the script which makes the installer packages should simply fetch
all files in init.d/ - right now this dir is populated for all Solaris and for
all Calendar builds... and more stuff will be added there step-by-step in the
future.

Comment 2

[Andrew Schultz]

Attachment: add init.d/*

Comment 3

[Andrew Schultz]

> (Mozilla 1.7b Linux/x86 Full installer) does not install the mozilla/init.d/
> directory (and the mozilla/init.d/README directory is missing, too).

the installer can't actually include a bare directory.  Without the README, the
installer would not create the init.d directory.

As far as I can tell, firefox/thunderbird have no packager.

If init.d files should be separated out between .xpi, it looks like the
S80calendar file needs to be handled in the calendar/Makefile.in (why is
calendar not in packages-unix?).  Or is "calendar" dead (long live Sunbird)?  

Comment 4

[Roland Mainz]

Andrew Schultz wrote:
> If init.d files should be separated out between .xpi, it looks like the
> S80calendar file needs to be handled in the calendar/Makefile.in (why is
> calendar not in packages-unix?). 

Mhhh... good idea... but how can this be implemented without breaking stuff ?

> Or is "calendar" dead (long live Sunbird)

calendar isn't dead. There is a bug to enable it in the default build (right now
only the Solaris builds ship with calendar enabled by default).

Comment 5

[Benjamin Smedberg]

Comment on attachment 144576 [details] [diff] [review]
add init.d/*

r=me, please add this to packages-static-unix also

Comment 6

[Benjamin Smedberg]

ok, hrm... I thought the solaris patch-checker was the only thing using this...
if calendar is using this too, we can't just do init.d/*, but have to manually
specify which files belong in each XPI.

Calendar is not part of the installer (yet), so we should not be including any
calendar files in packages-* manifests.

> As far as I can tell, firefox/thunderbird have no packager.

firefox has a win32 packager, but does not have a packager on any other platform yet

Comment 7

[Roland Mainz]

Benjamin Smedberg wrote:
> ok, hrm... I thought the solaris patch-checker was the only thing using 
> this...

I told you that the feature will be used more and more... :)

BTW: The Xprint and MathML font XPIs uses the "Pluggable Init script" framework,
too.

> if calendar is using this too, we can't just do init.d/*, but have to manually
> specify which files belong in each XPI.

Right now the calendar init script is only used when --enable-calendar specified
at build time so the patch (attachment 144576 [details] [diff] [review]) should work without problems with
installer builds. We should let the current patch "in" and make a reminder to
revisit the issue when calendar gets enabled in the default build.

Comment 8

[Andrew Schultz]

Attachment: list files explicitly

I'll attach a second (hackish) patch for calendar

Comment 9

[Andrew Schultz]

Attachment: patch for calendar

note that (in calendar's Makefile) "linux" really means not-win/mac/os2.

Comment 10

[Andrew Schultz]

Comment on attachment 144640 [details] [diff] [review]
patch for calendar

mostafah, can you review please?

Comment 11

[Mostafa Hosseini]

Comment on attachment 144640 [details] [diff] [review]
patch for calendar

This is a totally harmless change but I don't see its use. The change will add
the init.d/S80Calendar to the xpi package file. It will not install it at
install time and it will not change anything in the build process. That section
in the Makefile is just used for  creating a xpi manually with the "make xpi"
command, it is not used anywhere else.

Comment 12

[Andrew Schultz]

thanks for the quick review.

> This is a totally harmless change but I don't see its use.

If someone wants to use the installer to install calendar, it should include the
S80calendar script.  The calendar Makefile is the only place I found where an
.xpi could be made.

Comment 13

[chris hofmann]

Comment on attachment 144636 [details] [diff] [review]
list files explicitly

a=chofmann for 1.7

Comment 14

[Roland Mainz]

Comment on attachment 144636 [details] [diff] [review]
list files explicitly

This is wrong:
+bin/init.d/README
+bin/init.d/moz_patch_checker.dtksh
+bin/init.d/S02solaris_patchchecker.sh

The init.d/README explicitly says that files which do not match the
[SK][0-9][0-9]* must not be put into the init.d/ dir (the README is the only
exception). Therefore moz_patch_checker.dtksh sits in
bin/moz_patch_checker.dtksh ...

Comment 15

[chris hofmann]

Comment on attachment 144640 [details] [diff] [review]
patch for calendar

a=chofmann for 1.7

Comment 16

[Roland Mainz]

Comment on attachment 144636 [details] [diff] [review]
list files explicitly

Clearning a= request for now.

Comment 17

[Roland Mainz]

s/Clearning/Clearing/

Comment 18

[Andrew Schultz]

Attachment: one more time

Comment 19

[Mike Kaply [:mkaply]]

Comment on attachment 144665 [details] [diff] [review]
one more time

a=mkaply

Comment 20

[Andrew Schultz]

patches checked in by timeless

Comment 21

[Justin Wood (:Callek)]

hmm just a question (as it relates to Bug 245209)

This xpi thing with init.d does not get installed anywhere via the xpi, is just
/there/ if a user installing via xpi needs it?

if the latter is the case I don't see why we even have it in the xpi itself...at
least as long as we don't have a mechanism for having it added to build-runtime
from the xpi.

Further comments either here or in previously mentioned bug.