Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455168 (mon-review) - Review-Request: mon - General-purpose resource monitoring system
Summary: Review-Request: mon - General-purpose resource monitoring system
Keywords:
Status: CLOSED NEXTRELEASE
Alias: mon-review
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Marcela Mašláňová
QA Contact: Fedora Extras Quality Assurance
URL: http://netbsd.sk/~lkundrak/SPECS/mon....
Whiteboard:
Depends On: perl-Mon-review
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-13 11:34 UTC by Lubomir Rintel
Modified: 2010-04-22 18:48 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-25 07:48:41 UTC
mmaslano: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Lubomir Rintel 2008-07-13 11:34:20 UTC
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 11:43:28 UTC
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 12:29:13 UTC
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 13:04:22 UTC
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 14:12:08 UTC
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 15:02:57 UTC
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 15:29:30 UTC
(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 20:55:18 UTC
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 07:55:44 UTC
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 08:06:33 UTC
(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 12:23:47 UTC
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 15:57:35 UTC
cvs done.

Comment 12 Lubomir Rintel 2009-02-19 09:10:24 UTC
Imported and build. Thanks for review & CVS.

Comment 13 Need Real Name 2010-04-21 09:18:32 UTC
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 11:38:59 UTC
(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 11:45:11 UTC
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 18:48:54 UTC
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.