cvs commit: src/release Makefile

[Marcel Moolenaar]

On Fri, Jun 06, 2003 at 12:40:54AM +0300, Ruslan Ermilov wrote:
> > 
> > That's why I called the file .skip_ports. It doesn't mean readmes
> > are made, it means that they shouldn't be made (ie skipped). This
> > happens when readmes should not be made at all, or when they have
> > been made already. I've been more careful than you think :-)
> > 
> I noticed you were careful, I did.  But then please don't say
> "it is", because I meant what I said, "when ports^Wreadmes are
> really done".  ;)

Touche...

> > > > > When NOPORTS or NOPORTREADMES are defined, we should just not be
> > > > > doing the relevant parts of "make release".
> > > > 
> > > > Which is exactly what happens. By making the different parts of
> > > > a release cycle optional by checking for the existence of files,
> > > > you can more easily interfere by creating files or removing them.
> > > > Files are also a good way to maintain state across make invocations.
> > > > 
> > > What bugs me here is that we also (ab)use the /tmp/.skip_ports for
> > > remembering "NOPORTS || NOPORTREADMES".
> > 
> > It's not abuse, because it's designed for that purpose. Hence, you
> > don't like my design. Fair enough. Let me explain how I looked at
> > it:
> > 
> Mkay, you didn't mention it in the commit log.

Granted.

> > I think ``make release [list of defines]'' should in principle be
> > restarted with ``make rerelease [same list of defines]'', where
> > [same list of defines] is functional equivalent to [list of defines].
> > Exceptions are defines that control how you want the release to be
> > restarted (ie -DRELEASENOUPDATE).
> > 
> "make rerelease -DRELEASENOUPDATE" is normal, but your test
> case was "make release -DNOPORTS" and then "make rerelease
> -DRELEASENOUPDATE", which I consider as one of many ways
> to foot shoot themselves.  ;)

Actually, that wasn't my test case. I have to reread the thread to
know how and why it became part of the discussion. It doesn't really
matter in any case, so I'm not going to reread the thread :-)

> > > > > And of course, it
> > > > > should be possible to run "make -DNOPORTS release" first, and be
> > > > > able to run "make rerelease" later, and get the ports built.

Oh, wait a minute. Here it is. You gave this as an example... >:-)

> > > > It's not that simple AFAICT. If you follow a release -DNOPORTS -DNODOC
> > > > with a rerelease -DRELEASENOUPDATE, you won't have a ports tree
> > > > at all so you cannot possibly expect to have all the readmes built.
> > > > Your rerelease will probably fail.
> > > > 
> > > We could check if /usr/ports/Makefile exists, but this case is
> > > a self-foot-shooting IMO.  If you know you didn't check out ports
> > > sources with "make release", and expect "make rerelease" to build
> > > ports readmes, it should be clear that you don't want
> > > -DRELEASENOUPDATE.
> > 
> > Again, it's not that simple (unfortunately). One may need to update
> > the source tree and at the same time want ports. The point here is
> > not that we should allow al this fickleness, but that we have many
> > knobs and we have a lot of flexibility and most combinations simply
> > don't work if you don't have a FreeBSD Release GURU badge nailed to
> > your forehead and know how to circumvent the pitfalls.
> > 
> Who said that this should be simple?  ;)

You're right. It shouldn't. We should not deprive anyone from
nailing things to other things :-)

> > > I'm actually thinking of getting rid of "rerelease", and instead
> > > adding the -DNOCLEAN knob to "make release" to replace it.
> > 
> > Good thinking. I don't know how feasible it is, but it's definitely
> > something we should consider. Our release process has grown out of
> > control in some ways. Fresh solutions are needed...
> > 
> Mail me your concerns, I wish to consider them.

This probably takes some time. I think the general gist of it is that
the current process is not designed. It's merely the result of years
of enhancing, hooking and kludging. It lacks well-defined solutions to
well-defined problems.

> > It's not an anti-foot-shooting measure you're removing. It's the
> > basic functionality to have all the commands present in
> > ${CHROOTDIR}/mk in all cases, even if you don't actually use them.
> > It has been suggested before (in the 5.0-R timeframe) that having
> > the commands to make the readmes in ${CHROOT}/mk helps to manually
> > fiddle with the process. That's why the previous version had 
> > 
> > 	.if defined(NOPORTS) || defined(NOPORTREADMES)
> > 		echo "if false; then"		>> ${CHROOTDIR}/mk
> > 	.else
> > 		echo "if true; then"		>> ${CHROOTDIR}/mk
> > 	.endif
> > 
> How the "if false; then cd /usr/ports && make readmes" is really
> helpful?  How this is better than just "cd /usr/ports && make
> readmes" manually?  But okay, I agree we shouldn't be doing
> this in general.

It wasn't as helpful as it was supposed to be. At best it made it
visible what one had to do if one wanted to make the readmes by
hand. Since ${CHROOTDIR}/mk is recreated every time a release or
rerelease is started, it failed to be useful in most cases.

> > So: please do not conditionally put the commands in ${CHROOTDIR}/mk.
> > Have them unconditionally there, but have them conditionally executed.
> > 
> Sure, how is this then (better viewed as the diff to 1.780)?
> Feel free to commit it if you like it, I'm going to sleep
> now. ;)

Ok. Looks like a reasonable compromise. But let's wait until after
5.1-R has been built. This change will affect any release build
that starts from a -current source tree and I normally do that for
ia64. It's not that we have ia64 boxes to spare...

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net