#347 tor is not compliant with Fedora guidelines
Closed None Opened 9 years ago by sundaram.

= Proposal topic =

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

The maintainer should be convinced to fix it to be compliant or drop it so others can fix it


Added to 2010-03-16 meeting.

imho this ticket is too fuzzy, because it does not state which guidelines are not followed and the example bug report contains several issues, that have been addressed by the maintainer.

Fair enough. Let me point to a specific case

"Output in %post violates Fedora Packaging guidelines

WONTFIX; The alternative would be something like '%postun() script
failed'. RH/Fedora should fix its core utils before it can expect to
follow such guidelines."

I think the bigger issue is that many of Enrico's packages including clamav tend to be maintained in a very peculiar fashion where it is not necessarily against the guidelines but causes confusion among end users but not sure whether FESCo wants to really address that but direct violations should be fixed at the minimum.

There seems to in fact be no such guideline. ;)

I am going to remove this from the meeting at least for now.

There are guidelines for initscripts, the tor package is not following them. Several of the other annoyances are basically consequences of that.

Would you care to enumerate them here? The above complaint about output in %post doesn't seem to have any specific guideline forbidding it.

The guidelines state that scriptlets should always return 0 but not that they must not have any output at all. See https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Syntax (last two paragragraphs of the section).

https://fedoraproject.org/wiki/Packaging/Guidelines#Initscripts
Currently, only SystemV-style initscripts are supported in Fedora. There are detailed guidelines for SysV-style initscripts here: Packaging:SysVInitScript

And the linked https://fedoraproject.org/wiki/Packaging:SysVInitScript says very clearly what commands packages are supposed to run to install init scripts. The LSB tools tor-lsb is calling are NOT the commands to use. And the alternative tor-upstart is also not compliant (and the Fedora Upstart maintainers say very clearly that packages should NOT be shipping native Upstart initscripts at this time, which also matches the "Currently, only SystemV-style initscripts are supported in Fedora." statement from the guidelines).

So we are talking about initscripts now? I thought we were talking about scriptlets that are called from the spec?

The specfile scriptlet which is producing the error output is trying to install an initscript using LSB commands and complaining loudly on stderr or stdout when that fails due to redhat-lsb being just broken.

Added a note to the bug.

No response on bug.

I seee that ensc isn't cc'ed here. Adding.

From the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=532373#c11

"changing the scripts is not trivial and I am busy with more important tasks
than to fix something which is not broken.

I will add the proprietary RH initscripts for F-14 but can not tell when I have
time to implement them."

Shall we close this? Or do we wish to make sure the current stable versions get this as well?

Replying to [comment:13 kevin]:

From the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=532373#c11

"changing the scripts is not trivial and I am busy with more important tasks
than to fix something which is not broken.

I will add the proprietary RH initscripts for F-14 but can not tell when I have
time to implement them."

Shall we close this? Or do we wish to make sure the current stable versions get this as well?
Hi kevin,

I think using lsb initscripts instead of RH ones is not trivial a problem and should be fixed as soon as possible. There are many closed and unfixed bug reports in bugzilla against it.

See
https://bugzilla.redhat.com/show_bug.cgi?id=569933
https://bugzilla.redhat.com/show_bug.cgi?id=547051
https://bugzilla.redhat.com/show_bug.cgi?id=539558
https://bugzilla.redhat.com/show_bug.cgi?id=506828

All bugs for tor https://bugzilla.redhat.com/buglist.cgi?component=tor&product=Fedora

Most of those bugs are related to the lsb initscript.

Same here, this should be fixed ASAP for all supported releases (F11, F12, F13, F14/devel).

So fesco discussed it and we want to:

  1. wait a week to see if this can be cleaned up

  2. see if having a provenpackager fix it up is okay w/everyone.

Nirik,
you had some more comments on what you thought enrico could do?

Well, several things:

a) There shouldn't be any need to re-write the init script itself... simply use chkconfig to install it.

b) I think this update could be pushed to stable releases with the next non security update needed there. That way there wouldn't need to be a change just for this.

tor-lsb initscript uses /lib/lsb/init-functions instead of /etc/rc.d/init.d/functions, since it was first imported in Fedora several years ago, so it may need a re-written for the lsb initscript. But I think it's easy and safe to do so since tor is a small and also non-critical path package.
See
http://cvs.fedoraproject.org/viewvc/rpms/tor/devel/tor.lsb?revision=1.5&view=markup

I wonder why this package could be approved by package reviewer several years ago. The maintainer also add an upstart config for tor 3 months ago, so this package looks a bit different with all the other packages in Fedora.
See http://koji.fedoraproject.org/koji/buildinfo?buildID=162572

Can someone please add a pointer to a real big bug that is supposed to be fixed? The bugs listed in comment:14 are all the same (too many dependencies), which are afaik taken care of by splitting redhat-lsb in smaller packages. Also imho this whole ticket would be a lot clearer if there was a simple patch that shows which changes are expected to happen. This would also reduce any misunderstandings.

A redhat-lsb split is not a viable solution for stable releases.

And there's also the noisy RPM scriptlet issue.

Replying to [comment:20 kkofler]:

A redhat-lsb split is not a viable solution for stable releases.

And there's also the noisy RPM scriptlet issue.

But what makes any of this that urgent, that it needs to be fixed ASAP. Afaics the tor package does not suffer any functional bugs that are fixed by this.

The fact that it depends on half of Fedora, including stuff like qt3, is not a functional bug?

Till,
I agree about the urgency. Nothing's on fire here and to be honest, it's not like it is a massively used package.

I think it will be okay for this to wait.

However, as I said before, if a provenpackager wants to and CAN fix this - then by all means.

Replying to [comment:23 skvidal]:

Till,
I agree about the urgency. Nothing's on fire here and to be honest, it's not like it is a massively used package.

I think it will be okay for this to wait.

However, as I said before, if a provenpackager wants to and CAN fix this - then by all means.

Hi till,

As I know, tor is widely used in China to access websites blocked by government(e.g. blogspot, wordpress, python)

I also received a lot of complaints about tor as I mentioned in comment #14. In fact, tor depends on half of Fedora, including stuff like qt3 for several years´╝î so I wonder that the maintainer don't want to fix it even for F13. I think we should respect the complaints from fedora users.

Also I think using /lib/lsb/init-functions from redhat-lsb is meaningless and I don't know why the maintainer insist on using it instead of using /etc/rc.d/init.d/functions from initscripts. Other linux distributions like debian, arch, opensuse also use its own functions for initscripts instead of /lib/lsb/init-functions.

I think we should respect the complaints from fedora users.

I agree.

Also I think using /lib/lsb/init-functions from redhat-lsb is meaningless

And it's also not compliant with our guidelines for initscripts.

I've updated the bug again requesting a F13 update.

Will go ahead and close this out now.

In case this gets to the point where you need help from another maintainer, Paul Wouters has said he is willing to co-maintain or maintain this package on the devel list:

http://lists.fedoraproject.org/pipermail/devel/2010-June/137057.html

Login to comment on this ticket.

Metadata