headers
Berndt Josef Wulf | 1 Apr 2002 01:21
Picon

Re: Really annoying package situation

Mirko Thiesen wrote
> On Sun, 31 Mar 2002, Tracy Nelson wrote:
> 
> [...]
> > I recently did a sup.  I hadn't done this for a month or so.  When I tried
> > to make the new mozilla (0.9.9), I got build errors saying various packages
> > were installed, but newer versions were in pkgsrc.  Is there some command I
> > can use that will automatically rebuild any necessary packages?  Right now
> [...]
> 
> How du you build your packages? Usually a "make update" should take care
> of newer packages that are needed in order to build the one(s) you
> actually want to install. In my experience this mechanism works really
> fine.

A word of caution: Whilst 'make update' does what is expected it also
may cause a lot of grief. It was yesterday that I wanted to upgrade
the x11/blt package in order to fix a problem that was highlighted
during a bulk build. blt required a newer version of tcl/tk than that
was installed on this system. With only a couple of other packages
depending on it I went ahead with the update. What I didn't know was
it also required a new version of libtool, a utility that many
packages depend on. I fell into this trap and it was to late to stop the
process by the time I've noticed the deinstallation of packages such as
kde, qt, kdevelop etc...

Not happy Jane!

cheerio Berndt
--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Rauch | 1 Apr 2002 02:27
Favicon

Re: Really annoying package situation

Did you try ``make update''?

That's how I always build/install/update packages.  (You don't need to
have it previously installed; it deletes any obsolete packages and cleans
up the ...pkgsrc/*/*/work directories that it uses.)

That doesn't mean that it's always wrinkle-free: Critical libraries
sometimes get updated, and packages start to insist on the updated
version.  Further, especially when NetBSD isn't close to a release or a
patch-release, you can sometimes get a devastating effect: After pkgsrc
deinstalls every ``obstructing'' package and begins the rebuild process,
some package along the way may fail to build cleanly.  Then you can be
left with many of your more valued packages de-installed.

  ``I probably don't know what I'm talking about.'' --rauch <at> math.rice.edu
Permalink | Reply | 2 comments |
headers
Richard Rauch | 1 Apr 2002 02:31
Favicon

Re: Really annoying package situation

On Sun, 31 Mar 2002, Richard Rauch wrote:

> Did you try ``make update''?

Oh, bearing in mind your previous question, a little more closely:

That's ``make update'' in a particular package's directory.  E.g., ``cd
/usr/pkgsrc/lang/drscheme && make update''.

Update does *not* just ``update'' packages.  It installs them if they
aren't already installed.  So ``cd /usr/pkgsrc && make update'' would
presumably try to install every package---probably not what you wanted.

But, in the context of single package's pkgsrc directories, it does more
or less what you would expect.  (Save that it does not, I think, actually
check to see if the update is going to install a new version; it just
deinstalls the package, along with everything that depends upon it and
everything that it requires to have updated, then reinstalls everything
that it deinstalled.  I don't *think* that it will deinstall an acceptably
up-to-date package that the present package *depends* upon.  Otherwise,
it's pretty much unconditional.)

  ``I probably don't know what I'm talking about.'' --rauch <at> math.rice.edu
Permalink | Reply | 0 comments |
headers
Richard Rauch | 1 Apr 2002 02:50
Favicon

dhclient erases(!?) /etc/resolv.conf (fwd)

I decided to try running dhclient on my laptop in a different environment
today.  I was disturbed to discover that dhclient appears to have
oblitterated my old /etc/resolv.conf (rather blindly), and did not restore
it after I did a ``dhclient -r''.

Is this an intended feature, or was it just that no one considered that
someone might sometimes use DHCP and sometimes use a static config?

  ``I probably don't know what I'm talking about.'' --rauch <at> math.rice.edu
Permalink | Reply | 3 comments |
headers
Charlie Allom | 1 Apr 2002 04:18

Re: Really annoying package situation

On Sun, Mar 31, 2002 at 06:27:33PM -0600, Richard Rauch wrote:
> 
> some package along the way may fail to build cleanly.  Then you can be
> left with many of your more valued packages de-installed.

Has anyone thought of changing the way make update works, and moving
the pkg_delete part until after the compile is finished? I do this by
hand (been caught out by this too many times with no daemon to server
users)

so instead of:
pkg_delete -> make install
you get:
make -> pkg_delete -> make install

At the moment I just `make && make update` to be safe.

  C.
--

-- 
 charlie <at> rubberduck.com
 http://rubberduck.com/pgp.txt
 F848 3B10 D181 E5EC 84CD  9CA2 7686 6210 FB54 66D1
Permalink | Reply | 0 comments |
headers
Andrew Brown | 1 Apr 2002 05:45

Re: Starting jobs from init

>You can also use an `` <at> reboot'' crontab entry.  (I had the vague memory
>that I used this in the past with the effect that it auto-restarts, but I
>can't see any indication of that, now, in the man-page.  All that I can
>see, now, is that it runs it on every boot.)

 <at> reboot in the cron context refers to cron itself being "booted".
started, that is.  vixie cron also supports:

	 <at> yearly
	 <at> annually
	 <at> monthly
	 <at> weekly
	 <at> daily
	 <at> midnight
	 <at> hourly

some other cron versions support  <at> teatime.

--

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior <at> daemon.org             * "ah!  i see you have the internet
twofsonet <at> graffiti.com (Andrew Brown)                that goes *ping*!"
andrew <at> crossbar.com       * "information is power -- share the wealth."
Permalink | Reply | 0 comments |
headers
Richard Rauch | 1 Apr 2002 07:24
Favicon

Re: Really annoying package situation

I think that doing a ``make && make update'' combination will only help
over simply doing ``make update'' in the case of the current package, yes?

If the current package requirs a newer vesion of XXXlib, ``make'' won't
work, will it?  And when you do the ``make update'',
that's going to immediately remove (and try to rebuild) everything that
*depends* on the current package.

pkgsrc could probably be taught to deal with the second problem (it sounds
straightforward, but I'm not volunteering to do it...(^&).  But the first
problem looks harder.  (I seem to recall something about an idea from the
FreeBSD or OpenBSD camps, for building and installing packages in an
alternate location.  Could this be used to build/install one's way up the
dependancy graph?  Then when everything required is built (or known to
build), you could install for real.)

Perhaps the best thing to do at the moment is to backup your pkgsrc tree
(known to build everything that you currently have installed), then delete
all packages as well as the pkgsrc tree (might as well preserve the
distfiles, though), and install a new pkgsrc.  Then have a script run to
rebuild every package that you formerly had installed.  If everything is
okay, then keep the new pkgsrc (and updated packages).  Else, revert.  If
you manually prioritize the rebuilding, critical packages could be brought
back online quickly enough that this might not be too bad of an approach.

If you did this on a frequent basis, it might be worth while building
binary packages of everything as you go, so that reverting would be a
little less trouble.

  ``I probably don't know what I'm talking about.'' --rauch <at> math.rice.edu
(Continue reading)

Permalink | Reply | 0 comments |
headers
brook | 1 Apr 2002 12:28

2 bootable NetBSD partitions?

I would like to have 2 bootable MBR partitions for NetBSD (ID 169) on
one disk:  one for the -release version and one for -current.  Are
there any problems with such a setup?

I presume I can do the following to make it work.  Is this correct?

- create two MBR partitions
- designate each as partitions in the NetBSD disklabel
- install the OS in each
- the kernels must code their root filesystems to refer specifically
  to the appropriate partitions, e.g.,

	config		netbsd	root on wd0a type ffs	# one kernel
	config		netbsd	root on wd0h type ffs	# other kernel

Have I missed anything?

Cheers,
Brook
Permalink | Reply | 2 comments |
headers
Manuel Bouyer | 1 Apr 2002 15:07

Re: 2 bootable NetBSD partitions?

On Mon, Apr 01, 2002 at 11:28:13AM +0100, brook <at> biology.nmsu.edu wrote:
> I would like to have 2 bootable MBR partitions for NetBSD (ID 169) on
> one disk:  one for the -release version and one for -current.  Are
> there any problems with such a setup?
> 
> I presume I can do the following to make it work.  Is this correct?
> 
> - create two MBR partitions
> - designate each as partitions in the NetBSD disklabel
> - install the OS in each
> - the kernels must code their root filesystems to refer specifically
>   to the appropriate partitions, e.g.,
> 
> 	config		netbsd	root on wd0a type ffs	# one kernel
> 	config		netbsd	root on wd0h type ffs	# other kernel
> 
> Have I missed anything?

I think the disklabel will always be written to the first partition. One way
to work around it is to rename the first partition when installing on the
second.

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
--
Permalink | Reply | 0 comments |
headers
Mipam | 1 Apr 2002 22:14

Re: dhclient erases(!?) /etc/resolv.conf (fwd)

On Sun, Mar 31, 2002 at 06:50:03PM -0600, Richard Rauch wrote:
> I decided to try running dhclient on my laptop in a different environment
> today.  I was disturbed to discover that dhclient appears to have
> oblitterated my old /etc/resolv.conf (rather blindly), and did not restore
> it after I did a ``dhclient -r''.
> 
> Is this an intended feature, or was it just that no one considered that
> someone might sometimes use DHCP and sometimes use a static config?

Well, i guess it's intended.
In /sbin/dhclient-script (or /etc/....):

RESOLV=/etc/resolv.conf

make_resolv_conf() {
        if [ \( ! -z "$new_domain_name" \) -a \
	     \( ! -z "$new_domain_name_servers" \) ]; then
	     echo search $new_domain_name > $RESOLV
	     for nameserver in $new_domain_name_servers; do
		     echo nameserver $nameserver
	     done >> $RESOLV
        fi
}

Bye,

Mipam.
Permalink | Reply | 2 comments |

Gmane