rpmlint currently whines if a package installs one init script, and the init script name doesn't match the package name. If more than one init scripts are installed from one package, it doesn't emit this warning.
I don't think there are any naming guidelines for init scripts currently in effect, so I'm wondering if I should just filter out the warning in future rpmlint package revisions, or if people think that the way rpmlint currently wants the init scripts named would be make a good packaging guideline.
Thoughts?
On Sun, 2006-06-11 at 18:56 +0300, Ville Skyttä wrote:
rpmlint currently whines if a package installs one init script, and the init script name doesn't match the package name. If more than one init scripts are installed from one package, it doesn't emit this warning.
I don't think there are any naming guidelines for init scripts currently in effect, so I'm wondering if I should just filter out the warning in future rpmlint package revisions, or if people think that the way rpmlint currently wants the init scripts named would be make a good packaging guideline.
I think it is a good guideline if possible. When the name makes sense. package 'sendmail' makes sense to have a sendmail init.d script. There are a lot of examples though of package <name> that has a daemon component named <name>d. Maybe do a warning if the init script isn't %{name} || %{name}d ?
Dnia 11-06-2006, nie o godzinie 12:15 -0400, Jesse Keating napisał(a):
I think it is a good guideline if possible. When the name makes sense. package 'sendmail' makes sense to have a sendmail init.d script. There are a lot of examples though of package <name> that has a daemon component named <name>d. Maybe do a warning if the init script isn't %{name} || %{name}d ?
I still don't get why "sendmail" is good for package name and an init.d script name and "apache" is not. Sendmail is an MTA and I should start any MTA using for example "service smtpd start". Apache HTTP Server (see, it even doesn't contain "HTTPD" in its name!) is HTTP daemon, but not the only one out there, so while "service httpd start" looks good, the package name isn't good at all.
I vote for package name being package name and init script being named after the function it performs. I know that it makes it impossible to have 7 httpds installed at a time, but: 1. they can't co-exist nicely anyhow (every httpd is configured to run on port 80, even hacking config files and running another one on port 81 is not an option for many firewalls) and 2. if the program to do a function changes name or is replaced by another program (sendmail by postfix, uw-imap by dovecot or something), I don't have to learn, which program replaces which and does what. I just need to know which service do I need to enable in ntsysv/system-config-services. This is important to make Fedora user-friendly and to make many different Fedora FAQ-s to work for more than one release.
Alternatively, can't something like /etc/alternatives be used if many httpds/mtas/whatever are installed? Or even a multi-daemon system, where I have one /etc/init.d/httpd which can start any number of http daemons using their init scripts if they are configured (like /etc/init.d/network starts many interfaces depending on their configuration)?
Debian took another route, I even have to know which Apache HTTPD version is installed, because the old one is called "apache" and newer "apache2". At least one of many httpds isn't preferred over other ones by using name like "the only "httpd" in the distribution" ;)
Lam
Leszek Matok (Lam@Lam.pl) said:
I still don't get why "sendmail" is good for package name and an init.d script name and "apache" is not. Sendmail is an MTA and I should start any MTA using for example "service smtpd start".
Leads to file conflicts.
Apache HTTP Server (see, it even doesn't contain "HTTPD" in its name!) is HTTP daemon, but not the only one out there, so while "service httpd start" looks good, the package name isn't good at all.
httpd is required as part of the apache trademark stuff, IIRC.
Alternatively, can't something like /etc/alternatives be used if many httpds/mtas/whatever are installed? Or even a multi-daemon system, where I have one /etc/init.d/httpd which can start any number of http daemons using their init scripts if they are configured (like /etc/init.d/network starts many interfaces depending on their configuration)?
Alternatives should be used less, not more. :)
Bill
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Jesse Keating -
Leszek Matok -
Ville Skyttä