Bug #4
closedRework of nrelease
Added by joerg about 19 years ago. Updated about 18 years ago.
0%
Description
Hi all,
given that the nrelease part for pkgsrc is pretty much completely broken
and still depends on FreeBSD ports for the installer, attached is a
first stab at a pure pkgsrc nrelease. Requirements are pretty -- pkg_add
from pkgsrc, rsync for "make fetch". For many cases something like
PKGSRC_PKG_PATH = /nrelease
WITH_INSTALLER=1
in make.conf is enough. For cvsup I'll most likely provide a fake
package with a statically linked 1.2 binary, the CGI installer will
follow in the next days.
Joerg
Files
pkgsrc-nrelease.diff (10 KB) pkgsrc-nrelease.diff | joerg, 12/07/2005 06:27 PM | ||
pkgsrc-nrelease.diff (10.7 KB) pkgsrc-nrelease.diff | joerg, 12/09/2005 04:09 PM |
Updated by corecode about 19 years ago
joerg@britannica.bec.de wrote:
Hi all,
given that the nrelease part for pkgsrc is pretty much completely broken
and still depends on FreeBSD ports for the installer, attached is a
first stab at a pure pkgsrc nrelease. Requirements are pretty -- pkg_add
from pkgsrc, rsync for "make fetch". For many cases something like
PKGSRC_PKG_PATH = /nrelease
WITH_INSTALLER=1
in make.conf is enough. For cvsup I'll most likely provide a fake
package with a statically linked 1.2 binary, the CGI installer will
follow in the next days.
looks very good. This should go in as fast as possible so snapshot
builds work again. Thanks for the work!
cheers
simon
Updated by dillon about 19 years ago
:joerg@britannica.bec.de wrote:
:> Hi all,
:> given that the nrelease part for pkgsrc is pretty much completely broken
:> and still depends on FreeBSD ports for the installer, attached is a
:> first stab at a pure pkgsrc nrelease. Requirements are pretty -- pkg_add
:> from pkgsrc, rsync for "make fetch". For many cases something like
:> PKGSRC_PKG_PATH = /nrelease
:> WITH_INSTALLER=1
:> in make.conf is enough. For cvsup I'll most likely provide a fake
:> package with a statically linked 1.2 binary, the CGI installer will
:> follow in the next days.
:
:looks very good. This should go in as fast as possible so snapshot
:builds work again. Thanks for the work!
:
:cheers
: simon
Well, I like the idea but there are some issues.
I don't want to make the nrelease build dependant on a
binary packages directory sitting on packages.stura.uni-rostock.de.
Also, the 'check' target and the other convenience targets (to
fetch and configure pkgsrc and/or fetch required packages) need
to remain intact. I don't want programmers to be forced to use
obscure -D<LABEL> names to build common targets. The check target
in particular is very important as it prevents the user from having
to run through an entire buildworld before being told that something
is missing.
Its a good idea but it needs some work.
-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by joerg about 19 years ago
On Wed, Dec 07, 2005 at 11:04:36AM -0800, Matthew Dillon wrote:
I don't want to make the nrelease build dependant on a
binary packages directory sitting on packages.stura.uni-rostock.de.
It isn't. The situation hasn't changed at all compared to e.g. the
installer packages before. Consider it a temporary mean until the list
of packages is finished. The files can be moved e.g. to leaf or crater
for the release.
Also, the 'check' target and the other convenience targets (to
fetch and configure pkgsrc and/or fetch required packages) need
to remain intact. I don't want programmers to be forced to use
obscure -D<LABEL> names to build common targets. The check target
There are two possible situations. If you are building snapshots etc,
having knobs for /etc/make.conf is IMO the simpler solution. If you
want to customize the setup, knobs are much better, since it doesn't
need twenty different targets for all the interesting combinations.
This leaves out the question of the default (with or without installer),
but it is consistent with the rest of the framework.
in particular is very important as it prevents the user from having
to run through an entire buildworld before being told that something
is missing.
The check target can't be implemented correctly without also hard-coding
the package list. That's something I want to avoid. Adhoc checks are
possible like whether the bootstrap kit exists, but that doesn't cover
all cases of course.
Joerg
Updated by corecode about 19 years ago
Matthew Dillon wrote:
Well, I like the idea but there are some issues.
I don't want to make the nrelease build dependant on a
binary packages directory sitting on packages.stura.uni-rostock.de.
I think it's better to install a binary than requiring all pkgsrc to be
checked out... How about both possibilities?
For snapshot builds on chlamydia, i'd prefer the binary bootstrap by
far. All packages which are being installed on the iso need to come
from somewhere as well anyways, so requiring a binary bootstrap isn't
different either.
Also, the 'check' target and the other convenience targets (to
fetch and configure pkgsrc and/or fetch required packages) need
to remain intact. I don't want programmers to be forced to use
obscure -D<LABEL> names to build common targets. The check target
in particular is very important as it prevents the user from having
to run through an entire buildworld before being told that something
is missing.
That's just a matter of choice, really, and implementing these targets
shouldn't be a problem.
Updated by joerg about 19 years ago
On Wed, Dec 07, 2005 at 11:04:36AM -0800, Matthew Dillon wrote:
I don't want to make the nrelease build dependant on a
binary packages directory sitting on packages.stura.uni-rostock.de.
Also, the 'check' target and the other convenience targets (to
fetch and configure pkgsrc and/or fetch required packages) need
to remain intact. I don't want programmers to be forced to use
obscure -D<LABEL> names to build common targets. The check target
in particular is very important as it prevents the user from having
to run through an entire buildworld before being told that something
is missing.
Added compatibility targets installer_* (yes, I'd like to remove them at
some point in the future), added basic check target.
If no further objections occur, I'll commit this tomorrow.
If someone wants to update the cgi installer configuration, I'll provide
the package for that as well.
Joerg
Updated by drhodus about 19 years ago
I was wondering if anyone had worked on a good GUI plug in for the
installer that perhaps we could use default with the release.
-DR
Updated by dillon about 19 years ago
:> binary packages directory sitting on packages.stura.uni-rostock.de.
:> Also, the 'check' target and the other convenience targets (to
:> fetch and configure pkgsrc and/or fetch required packages) need
:> to remain intact. I don't want programmers to be forced to use
:> obscure -D<LABEL> names to build common targets. The check target
:> in particular is very important as it prevents the user from having
:> to run through an entire buildworld before being told that something
:> is missing.
:
:Added compatibility targets installer_* (yes, I'd like to remove them at
:some point in the future), added basic check target.
:
:If no further objections occur, I'll commit this tomorrow.
:
:If someone wants to update the cgi installer configuration, I'll provide
:the package for that as well.
:
:Joerg
That's looking better but the check code needs to be beefed up.
Someone running 'make installer_release' on a pristine system needs
to be told by the check code exactly what is needed before the build
occurs. As in cut-and-paste, just like the current nrelease build
does. You can either echo-out the appropriate command that the user
need to run, or you can provide a make target that gets the required
material. This includes the installation of /etc/mk.conf.
-Matt
Updated by joerg about 19 years ago
On Fri, Dec 09, 2005 at 12:32:32PM -0800, Matthew Dillon wrote:
You can either echo-out the appropriate command that the user
need to run, or you can provide a make target that gets the required
material. This includes the installation of /etc/mk.conf.
Two things are necessary: a working pkg_add and the results of make
fetch. The latter is the same as in the old routine, the former at least
very similiar. I'd document that requirement in UPDATING, other places
don't really make sense. For make fetch, rsync is also needed.
Joerg