ports/148777: [New Port] sysutils/qjail: Utility to deploy large number of jails quickly

[Chris Rees]

The following reply was made to PR ports/148777; it has been noted by GNATS.

From: Chris Rees <utisoft at gmail.com>
To: joeb at a1poweruser.com
Cc: bug-followup at freebsd.org
Subject: Re: ports/148777: [New Port] sysutils/qjail: Utility to deploy large
 number of jails quickly
Date: Sat, 20 Nov 2010 19:14:18 +0000

 On 20 November 2010 17:30, joeb <joeb at a1poweruser.com> wrote:
 > Chris Rees
 >
 > Thanks for the feedback.
 >
 > Every thing in this port was copied from ports already in the ports syste=
 m.
 > Even with the makefile having spaces it does install without any problems=
 .
 > It does not generate any errors like you say it will.
 >
 > When you talk about "redundant DISTFILES line" please be more detailed
 > because I cannot determine what you are referring to. =A0Even if you thin=
 k the
 > makefile DISTFILES=3D line is redundant it is not invalid and was put the=
 re as
 > documentation.
 >
 > There are many existing ports with no distinfo so I fail to see why you
 > think this is an error. This was done on purpose so I can update the dist
 > file with fixes or enactments without having to wait for months to get th=
 e
 > update commented because the makesum values have changed. =A0This techniq=
 ue is
 > communally used when the port make files will never change but allows the
 > maintainer to maintain the product without delays in moving updates into =
 the
 > existing port.
 >
 > You are incorrect, my makefile does not use =A0${INSTALL_DATA} it uses
 > do-install: and post-install:
 >
 > What you call extraneous newlines in the COMMENT/MAINTAINER block, I call
 > visual spacing so it looks nice when shown.
 >
 > If you run the port as is you will see how the "extraneous newlines" end =
 up
 > presenting a professional look in the output of the installed port.
 >
 > And when it comes to the messing with /etc/rc.d/jail file I was told by t=
 he
 > jail maintainer that he was addressing the bugs I pointed out in a up com=
 ing
 > release and that I should just replace it with my corrected one as part o=
 f
 > my port. So that is what I am doing.
 >
 > Now that I have addressed all your concerns, which resulted in no changes=
  to
 > the submitted port, lets get this port committed.
 >
 > Thanks for your help and interest.
 >
 
 My concerns have not all been addressed.
 
 Your missing distinfo is not permitted: Section 12.18 of the Porter's handb=
 ook.
 
 You can't change your distfiles without going through a committer.
 It's the rules; the source MUST be trusted, and by the users, not you.
 
 There are specific rules in how Makefiles should be laid out, and your
 stylistic newlines are also not encouraged. It's to make the job
 easier for the committers, and to make a consistent tree which is
 _really_ important for readability. Following the established rules is
 the 'professional' thing to do. You don't like it, start a discussion
 on the lists about changing policy, but until then you need to follow
 it.
 
 The spaces-instead-of-tabs are an error on many versions of make, and
 just because it works for you doesn't make it right.
 
 You still haven't run portlint -A
 
 In the do-install section, your port _does_ use ${INSTALL_DATA}. This
 is fine, but why are you using that then ${CP} underneath?
 
 Your PREFIX for the manpages is wrong.
 
 You can't write outside PREFIX, so no, your /etc modifications are
 _not_ OK. Some people have / on a read-only filesystem.
 
 Your port will work fine without the DISTFILES line, so it can be
 taken out. It's unnecessary, and will cause problems when updating the
 port; you'll have to change the filename manually.
 
 Again, I suggest you look at how you install the rc.d scripts in the
 handbook; you've done it wrong. rc.d scripts don't go in pkg-plist
 
 You should not list configuration files in pkg-plist; they get
 clobbered when upgrading.
 
 *Please* read the parts of the handbook linked above and THEN RUN
 portlint -A, as I suggested.
 
 The port 'working' for you does not make it acceptable for inclusion.
 
 You asked for guidelines, a committer will give you the same, or
 ignore the port as they have been. THAT is why it's been untouched for
 months, and the previous volunteer gave up on it. Properly made PRs
 are committed fairly quickly;
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/148208
 
 Chris