Bug 455168 - (mon-review) Review-Request: mon - General-purpose resource monitoring system
Review-Request: mon - General-purpose resource monitoring system
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
http://netbsd.sk/~lkundrak/SPECS/mon....
:
Depends On: perl-Mon-review
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-13 07:34 EDT by Lubomir Rintel
Modified: 2010-04-22 14:48 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-25 03:48:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mmaslano: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Lubomir Rintel 2008-07-13 07:34:20 EDT
SPEC: http://netbsd.sk/~lkundrak/SPECS/mon.spec
SRPM: http://netbsd.sk/~lkundrak/SRPMS/mon-1.2.0-2.el5.src.rpm

Description:

Mon is a general-purpose resource monitoring system.  It can be used
to monitor network service availability, server problems,
environmental conditions (i.e., the temperature in a room) or other
things. Mon can be used to test the condition and/or to trigger an
action upon failure of the condition.  Mon keeps the testing and
action-taking tasks as separate, stand-alone programs.

Mon is very extensible.  Monitors and alerts are not a part of mon, but
the distribution comes with a handful of them to get you started. This
means that if a new service needs monitoring, or if a new alert is
required, the mon server will not need to be changed.
Comment 1 Lubomir Rintel 2008-07-13 07:43:28 EDT
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"
Comment 2 Patrice Dumas 2008-07-13 08:29:13 EDT
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
Comment 3 Lubomir Rintel 2008-07-13 09:04:22 EDT
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?
Comment 4 Patrice Dumas 2008-07-13 10:12:08 EDT
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').
Comment 5 Lubomir Rintel 2008-07-13 11:02:57 EDT
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.

Comment 6 Patrice Dumas 2008-07-13 11:29:30 EDT
(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.

Comment 7 manuel wolfshant 2008-07-20 16:55:18 EDT
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.
Comment 8 Marcela Mašláňová 2008-07-23 03:55:44 EDT
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.
Comment 9 Patrice Dumas 2008-07-23 04:06:33 EDT
(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.
Comment 10 Lubomir Rintel 2008-07-23 08:23:47 EDT
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
Comment 11 Kevin Fenzi 2008-07-23 11:57:35 EDT
cvs done.
Comment 12 Lubomir Rintel 2009-02-19 04:10:24 EST
Imported and build. Thanks for review & CVS.
Comment 13 Need Real Name 2010-04-21 05:18:32 EDT
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.
Comment 14 Lubomir Rintel 2010-04-21 07:38:59 EDT
(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.
Comment 15 Need Real Name 2010-04-21 07:45:11 EDT
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.
Comment 16 Jason Tibbitts 2010-04-22 14:48:54 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.