ports/148777: [New Port] sysutils/qjail: Utility to deploy large number of jails quickly
Chris Rees
utisoft at gmail.com
Sat Nov 20 19:20:10 UTC 2010
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
More information about the freebsd-ports-bugs
mailing list