Bug 455168 (mon-review)

mon.i386: E: non-readable /etc/mon/userfile 0600
mon.i386: E: setgid-binary /usr/lib/mon/mon.d/dialin.monitor.wrap uucp 02755
mon.i386: E: non-standard-executable-perm /usr/lib/mon/mon.d/dialin.monitor.wrap
02755

These are intentional.

mon.i386: W: incoherent-subsys /etc/rc.d/init.d/mon $prog
mon.i386: W: incoherent-subsys /etc/rc.d/init.d/mon $prog
mon.i386: W: incoherent-subsys /etc/rc.d/init.d/mon $prog

False positive, $prog == "mon"

In my opinion, a 3 letter package name is calling for trouble. I try
to give reasons here:

https://fedoraproject.org/wiki/PackagingTricks#Use_of_common_namespace

Patrice: Thanks for comment. Though your opinion is more-or-less reasonable,
there's a guideline for naming packages after names of upstream projects. Do you
suggest an alternative name?

My suggestion would be first to contact upstream and present them the
arguments, 'explaining that in fedora we have to consider a broader 
perspective of a mix of packages of unknown size.'

And if it fails then look over the web if there are already existing 
clashes, if so try to weight which should have precedence and find the name
accordingly (it may end up being 'mon').

Changing the upstream name is out of question here, I'd say, especially in case
of a well-established project with generally recognized name. Picking the
package name of first come -- first serve basis is perfectly just here.

(In reply to comment #5)
> Changing the upstream name is out of question here, I'd say, especially in case
> of a well-established project with generally recognized name. Picking the
> package name of first come -- first serve basis is perfectly just here.

No, it is not. The name should always be specific. First come first serve is 
not playing nice with other potential softwares. That being said, this 
project is the oldest and well established, so the name should certainly be 
used for that project. But still, contacting upstream about the genericity
of the name would seem to be better to me.

mon is a known project with a well established name, coming from a reputable source.
Generally speaking 3 letter projects do call for trouble, but in this case we
are dealing with the 'original" (at least I know about it for several years). I
do not think changing it's name just for fedora is worth the effort and I more
than welcome packaging it in Fedora, especially if an EPEL version is also taken
into consideration.

Package is ok.

<citation>
If upstream cannot be convinced, it may be wise to search over the internet for
packages that already use that name and think about which one should keep the
main name, and a prefix or postfix can be used in fedora if disambiguation is
needed. 
</citation>

I agree with previous posts, but name Mon is already used in debian. Different
names for programmes in different distros are definitely bad thing and make
users angry.

(In reply to comment #7)

> Generally speaking 3 letter projects do call for trouble, but in this case we
> are dealing with the 'original" (at least I know about it for several years).
> I do not think changing it's name just for fedora is worth the effort 

It's also what I said in Comment #6. I have no objection about having
this package called mon in fedora, it is the best choice in my opinion, 
but at the same time, I try to raise awareness about name collisions in 
the distribution.

Patrice: Thanks for your suggestion, and activity in field of avoiding package
name clashes. I recently hit about the same problem with two projects called
"plexus" and wished the upstream would have thought twice before picking a name,
so I especially appreciate your efforts.

Marcela: Much thanks for the review!

New Package CVS Request
=======================
Package Name: mon
Short Description: General-purpose resource monitoring system
Owners: lkundrak
Branches: F-8 F-9 EL-5
Cvsextras Commits: yes

cvs done.

Imported and build. Thanks for review & CVS.

I'm not sure how this package passed review: it's broken out of the box, doesn't work on 64-bit and has a missing dependency. See bug 584281.

(In reply to comment #13)
> I'm not sure how this package passed review: it's broken out of the box,
> doesn't work on 64-bit and has a missing dependency. See bug 584281.    

I'm not sure how could we have bugs in the package collection at all when the packages are being reviewed before import. Also, I'm not sure if it's a good idea to post crap in a closed review request just to offend the reviewer.

Mon deals with missing dependencies gracefully, expecting not that the required tools are not present, making the first two issues somehow philosophical issues, rather than technical. But, given we don't have a soft dependency mechanism, I agree with your point here, just don't think it's that serious to skip. (By the way, obfuscation of perl's module import mechanism with eval around use caused Authen::PAM dependency to be ignored by automatic Perl dependency generation mechanism, thus it was somehow intended by upstream as well).

Regarding the portability problem, packaging guidelines require the packager as well as the reviewer to test and run on at least one platform. Sure that's no good excuse for a broken package, shame on me for not realizing that there's a problem with that, but I think it is completely understandable how could the reviewer not notice that as well.

My intention was to highlight problems with an approved package with a view to raising problems in the review process. It was not intended to offend any particular person.

The package was approved just a couple of months shy of two years ago.  I don't see the point of complaining about the review or the review process now, since the package has certainly changed since it was reviewed.