Re: Upgrading to 7.0 - stupid requirements

[Mark Kirkwood]

FWIW - I have just completely *recompiled* my userland after the 6->7 
upgrade - i.e:


# portupgrade --batch -fa

on a PIII 1.26Ghz system in just under 2 days (i.e over the weekend) for 
836 packages - desktop system with Gnome etc. So it's not actually too 
bad. Using the packages option on faster hardware should be pretty painless.


Cheers

Mark

Marko Lerota wrote:



# portupgrade -faP

etc...

Why!!! Do you know how much time I have to spend with my PC to reinstall
all of this programs from ports? Only openoffice takes one day! And where 
is Gnome and such...There must be other way...I would not reinstall my 
packages ;)


T


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Michael Gratton]

On Mon, 2008-03-24 at 23:01 -0700, Chris H. wrote:
> changes, simply add
> include conf/custom1.conf
> include conf/custom2.conf
> include conf/custom... etc... to the http[s]d.conf, and the custom
> changes/additions are sucked in "magically". Apache has been like that
> since the very beginning. I don't see where Linux has improved on this
> at all.
[snip]
> use the following line in your http[s]d.conf file
> include vhost/*
> and your done. Linux had nothing to do with this. You can thank NCSA
> for this scheme. :)

Yes, Debian just does this by default.

This is in contrast to most (all?) FBSD ports that attempt to munge your
central config file when it needs to (e.g. modifying httpd.conf when
installing PHP[0]) or just don't bother, both of which are fails.

/Mike

[0] not that I'm alleging the PHP ports do this, but it's a good example
of when such a thing needs to happen.

-- 
Michael Gratton <[EMAIL PROTECTED]> 
Quuxo Software 


signature.asc
Description: This is a digitally signed message part

Re: Upgrading to 7.0 - stupid requirements

[Chris H.]

Quoting Michael Gratton <[EMAIL PROTECTED]>:


On Sat, 2008-03-22 at 20:59 -0700, Freddie Cash wrote:

On Sat, Mar 22, 2008 at 5:07 PM, Anders Nordby <[EMAIL PROTECTED]> wrote:
>  conf.d (custom configuration)
>  sites-available (virtualhost configuration)
>  sites-enabled (symlinks for enabled virtualhosts)
>  mods-available (available Apache modles)
>  mods-enabled (symlinks for enabled Apache modules)

Oh, gods, please, no!  That is one of the things I absolutely hate
about Debian (and its derivatives).  There are some packages on Debian
where they use separate text files for each configuration option
(ProFTPd, for examples).  It is a huge mess of directories and files
that makes it a *royal* PITA to edit at the CLI.


Actually, it makes two things really easy:

1. Automated installation of configuration required by other packages,
without them all munging and potentially breaking a single, central
config file. For example, you have Apache installed, and you want to
install PHP, the PHP port/package drops a file with the needed config
files into /etc/apache2/conf.d. No ad-hoc editing of httpd.conf
required, no loss of the work you did to customise it in the first
place.

/etc/make.conf will easily allow you to make "boilerplate" install/make
schemes already.
http[s]d.conf can always remain exactly the same. For any desired (custom)
changes, simply add
include conf/custom1.conf
include conf/custom2.conf
include conf/custom... etc... to the http[s]d.conf, and the custom
changes/additions are sucked in "magically". Apache has been like that
since the very beginning. I don't see where Linux has improved on this
at all.


2. As someone else pointed out, managing large numbers of vhosts (which
is really just a special case of #1.

use the following line in your http[s]d.conf file
include vhost/*
and your done. Linux had nothing to do with this. You can thank NCSA
for this scheme. :)




Yes, a scheme like that is better for GUI tools, but it really makes
things more difficult for non-GUI users/uses (like headless servers
managed via SSH).


It has nothing to do with GUI tools.


One of the things I *really* like about FreeBSD is that it has the
"one config file per app/system" setup.


Until you install that one last port that breaks the config file you
spent hours tweaking.

Again - YOU, the SA are given the control with FBSD. Simply create an
/etc/make.conf with options that will be used with ALL your boxen. Then
simply add any host specific options as required/desired. Leaving you
less to keep track of, and less opportunity for errors to creep in. :)

--Chris H



/Mike

--
Michael Gratton <[EMAIL PROTECTED]>
Quuxo Software 





--
panic: kernel trap (ignored)



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Michael Gratton]

On Sun, 2008-03-23 at 10:06 -0700, Freddie Cash wrote:
> On Sat, Mar 22, 2008 at 10:21 PM, Michael Gratton <[EMAIL PROTECTED]> wrote:
> >  Actually, it makes two things really easy:
> >
> >  1. Automated installation of configuration required by other packages,
> >  without them all munging and potentially breaking a single, central
> >  config file. For example, you have Apache installed, and you want to
> >  install PHP, the PHP port/package drops a file with the needed config
> >  files into /etc/apache2/conf.d. No ad-hoc editing of httpd.conf
> >  required, no loss of the work you did to customise it in the first
> >  place.
> 
> A conf.d/ type directory for other ports to put config snippets into
> might be useful, as it follows from the "include this file" setup.
> Or, install the PHP config details into /usr/local/share/php/conf/ or
> similar (since it's part of PHP) and then Include it into your
> httpd.conf as needed.

Yes, conf.f is very useful. Having to add a manual Include (if the
software even supports it is less so, if you quite reasonably expect a
port/package to Just Work after having installed it.

> >  2. As someone else pointed out, managing large numbers of vhosts (which
> >  is really just a special case of #1.
> 
> Same as above.  No multitude of directories full of symlinks needed.

It does seem like overkill, until you start using it.

The main reason it is useful (apart from avoiding the risk of a bad edit
nuking some or all of your config) is that you can use standard command
line tools, or very basic custom scripts to easily add, delete, enable,
disable and query vhosts. All without having to write a parser for the
script or having to navigate the config file in a text editor.

Done right, the same tools can be used for many different servers that
support the same config file scheme.

If you really need to edit all in one hit, use `vi *' or sed or
something.

> httpd.conf so we can edit them all at once, which we do quite a bit).

Why do you frequently need to edit all vhosts at once? Do you like to
change the location for everyone's log files, making it fun for people
to find them? :) But seriously, I find this surprising - once running,
the only thing most need to do is enable/disable or delete one here or
there, or perform the occasional requested config tweak.

> Which is why the ports framework needs more support (or better details
> of the support in the Porter's Handbook) for maintainers to say "this
> is the config file, install it as config.sample, compare MD5 to
> installed config, replace iff identical", without having to write
> custom install targets for each port.

Yes, and that works fine until you install PHP and it nukes your Apache
config file...

/Mike

-- 
Michael Gratton <[EMAIL PROTECTED]> 
Quuxo Software 


signature.asc
Description: This is a digitally signed message part

Re: Upgrading to 7.0 - stupid requirements

[Freddie Cash]

On Sat, Mar 22, 2008 at 10:21 PM, Michael Gratton <[EMAIL PROTECTED]> wrote:
> On Sat, 2008-03-22 at 20:59 -0700, Freddie Cash wrote:
>  > On Sat, Mar 22, 2008 at 5:07 PM, Anders Nordby <[EMAIL PROTECTED]> wrote:
>
> > >  conf.d (custom configuration)
>  > >  sites-available (virtualhost configuration)
>  > >  sites-enabled (symlinks for enabled virtualhosts)
>  > >  mods-available (available Apache modles)
>  > >  mods-enabled (symlinks for enabled Apache modules)
>  >
>  > Oh, gods, please, no!  That is one of the things I absolutely hate
>  > about Debian (and its derivatives).  There are some packages on Debian
>  > where they use separate text files for each configuration option
>  > (ProFTPd, for examples).  It is a huge mess of directories and files
>  > that makes it a *royal* PITA to edit at the CLI.
>
>  Actually, it makes two things really easy:
>
>  1. Automated installation of configuration required by other packages,
>  without them all munging and potentially breaking a single, central
>  config file. For example, you have Apache installed, and you want to
>  install PHP, the PHP port/package drops a file with the needed config
>  files into /etc/apache2/conf.d. No ad-hoc editing of httpd.conf
>  required, no loss of the work you did to customise it in the first
>  place.

A conf.d/ type directory for other ports to put config snippets into
might be useful, as it follows from the "include this file" setup.
Or, install the PHP config details into /usr/local/share/php/conf/ or
similar (since it's part of PHP) and then Include it into your
httpd.conf as needed.

>  2. As someone else pointed out, managing large numbers of vhosts (which
>  is really just a special case of #1.

Same as above.  No multitude of directories full of symlinks needed.
Although this is more of a personal preference than anything (we keep
all our virtualhosts in a single config file included into the main
httpd.conf so we can edit them all at once, which we do quite a bit).

>  > One of the things I *really* like about FreeBSD is that it has the
>  > "one config file per app/system" setup.
>
>  Until you install that one last port that breaks the config file you
>  spent hours tweaking.

Which is why the ports framework needs more support (or better details
of the support in the Porter's Handbook) for maintainers to say "this
is the config file, install it as config.sample, compare MD5 to
installed config, replace iff identical", without having to write
custom install targets for each port.

-- 
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Freddie Cash]

On Sat, Mar 22, 2008 at 9:20 PM, Garrett Wollman
<[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
>
> Freddie Cash writes:
>  >Oh, gods, please, no!  That is one of the things I absolutely hate
>  >about Debian (and its derivatives).  There are some packages on Debian
>  >where they use separate text files for each configuration option
>  >(ProFTPd, for examples).  It is a huge mess of directories and files
>  >that makes it a *royal* PITA to edit at the CLI.
>  >
>  >Yes, a scheme like that is better for GUI tools, but it really makes
>  >things more difficult for non-GUI users/uses (like headless servers
>  >managed via SSH).
>
>  Try managing a few hundred mostly-but-not-entirely-identical machines
>  and you really begin to appreciate the value of this approach.  It is
>  orders of magnitude easier to drop one file into the central config
>  repository that does *one thing* than it is to manage a dozen
>  not-quite-identical copies of a monolithic configuration file, keeping
>  in sync the parts that are supposed to be in sync, and keeping the
>  parts that are supposed to be different, different.
>
>  If FreeBSD were able to do this, it might have a bit more traction at
>  my place of employment.

We do, using a "include file" setup.  A main, monolothic config file
for everything that is common between all systems, and then include a
separate file that is specific to that machine.  We based this on the
/etc/rc.conf vs /etc/rc.conf.local setup.  Works quite nicely across
our 100+ servers.

No need to break things down to the "multiple directories full of
symlinks and itty-bitty files" setup, though.

-- 
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Stefan Lambrev]

Garrett Wollman wrote:

In article <[EMAIL PROTECTED]>,
Freddie Cash writes:

  

Oh, gods, please, no!  That is one of the things I absolutely hate
about Debian (and its derivatives).  There are some packages on Debian
where they use separate text files for each configuration option
(ProFTPd, for examples).  It is a huge mess of directories and files
that makes it a *royal* PITA to edit at the CLI.

Yes, a scheme like that is better for GUI tools, but it really makes
things more difficult for non-GUI users/uses (like headless servers
managed via SSH).



Try managing a few hundred mostly-but-not-entirely-identical machines
and you really begin to appreciate the value of this approach.  It is
orders of magnitude easier to drop one file into the central config
repository that does *one thing* than it is to manage a dozen
not-quite-identical copies of a monolithic configuration file, keeping
in sync the parts that are supposed to be in sync, and keeping the
parts that are supposed to be different, different.

If FreeBSD were able to do this, it might have a bit more traction at
my place of employment.
  
I'm little puzzled. What actually FreeBSD and current portsystem + tools 
are not able to do?!?!

You mean "I do not know how to do it" may be?


-GAWollman
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
  


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Stefan Lambrev]

Greetings,

Eirik Øverby wrote:

On Mar 23, 2008, at 08:28, Matthew Seaman wrote:


Freddie Cash wrote:


All that's really needed is a more formalised process for handling
upgrading config files, with as much as possible managed via the ports
framework itself.  Something that dictates the name of the config
file, and that compares the config file from the port against the
installed config file (or against an md5 of the port config file) and
only replaces it if it is unchanged.  Something that is part of the
make system.


Most ports that install configuration files actually do this already.
It's generally why you'll find that a sample configuration file is
considered part of the port, but the actuall live configuration file
is not.  The port will only feel free to meddle with the config file if
it is still identical to the sample file.


There are a few exceptions to this rule: The courier authdaemon ports, 
for instance, are notorious for overwriting my carefully-crafted 
configuration files when upgrading. I loathe those ports (or apps - 
not sure who's to blame) for that reason alone. In fact, it not only 
installs a config.dist file (which is fine), but it ALSO overwrites 
the current config. A cardinal sin, if there ever were any..
I'm using FreeBSD + courrier for imap/pop3 and auth for more then 2 
years till now and this never happen to me.

Though I'm using portupgrade to upgrade those ports.
The only port that destroyed my configuration file is blocksshd, I 
reported it and it was fixed in 2 days.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Torfinn Ingolfsen]

On Sun, 23 Mar 2008 08:40:31 +0100
Eirik Øverby <[EMAIL PROTECTED]> wrote:

> There are a few exceptions to this rule: The courier authdaemon
> ports, for instance, are notorious for overwriting my
> carefully-crafted configuration files when upgrading. I loathe those

Then I hope you have filed a PR for this bug?
There should be no exceptions - ports should never overwrite config
files.
-- 
Regards,
Torfinn Ingolfsen

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Eirik Øverby]

On Mar 23, 2008, at 08:28, Matthew Seaman wrote:


Freddie Cash wrote:


All that's really needed is a more formalised process for handling
upgrading config files, with as much as possible managed via the  
ports

framework itself.  Something that dictates the name of the config
file, and that compares the config file from the port against the
installed config file (or against an md5 of the port config file) and
only replaces it if it is unchanged.  Something that is part of the
make system.


Most ports that install configuration files actually do this already.
It's generally why you'll find that a sample configuration file is
considered part of the port, but the actuall live configuration file
is not.  The port will only feel free to meddle with the config file  
if

it is still identical to the sample file.


There are a few exceptions to this rule: The courier authdaemon ports,  
for instance, are notorious for overwriting my carefully-crafted  
configuration files when upgrading. I loathe those ports (or apps -  
not sure who's to blame) for that reason alone. In fact, it not only  
installs a config.dist file (which is fine), but it ALSO overwrites  
the current config. A cardinal sin, if there ever were any..


Now I must say I'm with the people who think that one should follow  
the one-port-one-configfile approach; however for a somewhat different  
reason: The closer a port sticks with the "default" configuration  
files, or samples if you will, of the software in question, the less  
FreeBSD-specific knowledge needs to be built to manage the port. If  
debian splits up the config into a forest of includefiles and  
symlinks, that might be good for a particular purpose, but it's  
something I'd prefer to do myself if the need is there. I've done  
similiar things on some occations, but that is, and IMO should be,  
"homebrew".


Also, making ports adhere to a much stricter configuration regime  
would make the uptake of new ports slow down considerably. I believe  
(though I have no numbers to back this up, so it is of course pure  
speculation) that the large number of ports available is at least  
partly due to the fact that making an initial port is relatively easy  
and straight forward.


Just my 2 cents.

/Eirik
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Matthew Seaman]

Freddie Cash wrote:


All that's really needed is a more formalised process for handling
upgrading config files, with as much as possible managed via the ports
framework itself.  Something that dictates the name of the config
file, and that compares the config file from the port against the
installed config file (or against an md5 of the port config file) and
only replaces it if it is unchanged.  Something that is part of the
make system.


Most ports that install configuration files actually do this already.
It's generally why you'll find that a sample configuration file is
considered part of the port, but the actuall live configuration file
is not.  The port will only feel free to meddle with the config file if
it is still identical to the sample file.

Cheers,

Matthew
--
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
 Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
 Kent, CT11 9PW



signature.asc
Description: OpenPGP digital signature

Re: Upgrading to 7.0 - stupid requirements

[Michael Gratton]

On Sat, 2008-03-22 at 20:59 -0700, Freddie Cash wrote:
> On Sat, Mar 22, 2008 at 5:07 PM, Anders Nordby <[EMAIL PROTECTED]> wrote:
> >  conf.d (custom configuration)
> >  sites-available (virtualhost configuration)
> >  sites-enabled (symlinks for enabled virtualhosts)
> >  mods-available (available Apache modles)
> >  mods-enabled (symlinks for enabled Apache modules)
> 
> Oh, gods, please, no!  That is one of the things I absolutely hate
> about Debian (and its derivatives).  There are some packages on Debian
> where they use separate text files for each configuration option
> (ProFTPd, for examples).  It is a huge mess of directories and files
> that makes it a *royal* PITA to edit at the CLI.

Actually, it makes two things really easy:

1. Automated installation of configuration required by other packages,
without them all munging and potentially breaking a single, central
config file. For example, you have Apache installed, and you want to
install PHP, the PHP port/package drops a file with the needed config
files into /etc/apache2/conf.d. No ad-hoc editing of httpd.conf
required, no loss of the work you did to customise it in the first
place.

2. As someone else pointed out, managing large numbers of vhosts (which
is really just a special case of #1.

> Yes, a scheme like that is better for GUI tools, but it really makes
> things more difficult for non-GUI users/uses (like headless servers
> managed via SSH).

It has nothing to do with GUI tools.

> One of the things I *really* like about FreeBSD is that it has the
> "one config file per app/system" setup.

Until you install that one last port that breaks the config file you
spent hours tweaking.

/Mike

-- 
Michael Gratton <[EMAIL PROTECTED]> 
Quuxo Software 


signature.asc
Description: This is a digitally signed message part

Re: Upgrading to 7.0 - stupid requirements

[Garrett Wollman]

In article <[EMAIL PROTECTED]>,
Freddie Cash writes:

>Oh, gods, please, no!  That is one of the things I absolutely hate
>about Debian (and its derivatives).  There are some packages on Debian
>where they use separate text files for each configuration option
>(ProFTPd, for examples).  It is a huge mess of directories and files
>that makes it a *royal* PITA to edit at the CLI.
>
>Yes, a scheme like that is better for GUI tools, but it really makes
>things more difficult for non-GUI users/uses (like headless servers
>managed via SSH).

Try managing a few hundred mostly-but-not-entirely-identical machines
and you really begin to appreciate the value of this approach.  It is
orders of magnitude easier to drop one file into the central config
repository that does *one thing* than it is to manage a dozen
not-quite-identical copies of a monolithic configuration file, keeping
in sync the parts that are supposed to be in sync, and keeping the
parts that are supposed to be different, different.

If FreeBSD were able to do this, it might have a bit more traction at
my place of employment.

-GAWollman
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Freddie Cash]

On Sat, Mar 22, 2008 at 5:07 PM, Anders Nordby <[EMAIL PROTECTED]> wrote:
>  On Wed, Mar 19, 2008 at 09:28:35PM +0100, Oliver Fromme wrote:
>  >> If this thing can be solved (I'm not programmer so I don't know) I can
>  >> donate some amount of $ for development. I think that this would make
>  >> lots of people happy.
>  > I have to admit I see no way how the problem could
>  > be solved in a different way, I'm afraid.
>
>  By FreeBSD adpoting some variant of apt-get for ports maybe? And by
>  making the ports install configuration files in such a way that
>  upgrading is more easy?gThe way it is now, you typically have to move
>  away old config files during/before an upgrade, and manually merge with
>  the new default of whichever program you are upgrading so that you get
>  new defaults. A good example is the way Debian installs Apache I guess,
>  with a directory structure like this under /etc/apache2:
>
>  conf.d (custom configuration)
>  sites-available (virtualhost configuration)
>  sites-enabled (symlinks for enabled virtualhosts)
>  mods-available (available Apache modles)
>  mods-enabled (symlinks for enabled Apache modules)

Oh, gods, please, no!  That is one of the things I absolutely hate
about Debian (and its derivatives).  There are some packages on Debian
where they use separate text files for each configuration option
(ProFTPd, for examples).  It is a huge mess of directories and files
that makes it a *royal* PITA to edit at the CLI.

Yes, a scheme like that is better for GUI tools, but it really makes
things more difficult for non-GUI users/uses (like headless servers
managed via SSH).

One of the things I *really* like about FreeBSD is that it has the
"one config file per app/system" setup.  There's
/etc/defaults/rc.conf, /etc/rc.conf, and /etc/rc.conf.local.  There's
not a dozen /etc/init.d/rc*.d directories filled with tonnes of
symlinks.

There's /usr/local/etc/apache2/httpd.conf and not a bunch of
directories filled with symlinks.

There's /usr/local/etc/proftpd.conf and not a directory full of 10 byte files.

All that's really needed is a more formalised process for handling
upgrading config files, with as much as possible managed via the ports
framework itself.  Something that dictates the name of the config
file, and that compares the config file from the port against the
installed config file (or against an md5 of the port config file) and
only replaces it if it is unchanged.  Something that is part of the
make system.

-- 
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Anders Nordby]

Hi,

On Wed, Mar 19, 2008 at 09:28:35PM +0100, Oliver Fromme wrote:
>> If this thing can be solved (I'm not programmer so I don't know) I can
>> donate some amount of $ for development. I think that this would make
>> lots of people happy.
> I have to admit I see no way how the problem could
> be solved in a different way, I'm afraid.

By FreeBSD adpoting some variant of apt-get for ports maybe? And by
making the ports install configuration files in such a way that
upgrading is more easy?gThe way it is now, you typically have to move
away old config files during/before an upgrade, and manually merge with
the new default of whichever program you are upgrading so that you get
new defaults. A good example is the way Debian installs Apache I guess,
with a directory structure like this under /etc/apache2:

conf.d (custom configuration)

sites-available (virtualhost configuration)

sites-enabled (symlinks for enabled virtualhosts)

mods-available (available Apache modles)

mods-enabled (symlinks for enabled Apache modules)

Of course, this would be a huge task to undertake. But why aren't we
doing it already? IMO the biggest problems with ports today is the lack
of an easy to use, powerful binary (!) upgrade system which can do
upgrades more efficiently for most uses/users.

PS: Your description of how to upgrade your ports matches with what I do
after a major OS upgrade (delete all, then reinstall). For sure it
works. But it isn't really efficient. Don't you agree? By not having an
efficient upgrade prodcedure, you typically end up not getting software
updates done as often as you might like. At least that is how it is for
me.

Cheers,

-- 
Anders.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Kevin Oberman]

> Date: Fri, 21 Mar 2008 15:59:27 +1100
> From: Peter Jeremy <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
> On Wed, Mar 19, 2008 at 07:43:25PM +0100, Marko Lerota wrote:
> >time from ports because there are only small portion of precompiled 
> >packages.
> 
> There should be a fairly complete set of packages for 7.0-RELEASE.
> There can never be a totally complete set of packages for legal
> reasons - the licenses on some ports do not permit them to be packaged.
> 
> >This thing should be solved.
> 
> Please offer some suggestions on how you would resolve the problem.
> 
> >And If I upgrade the OS I dont want to recompile ports for that.
> 
> You don't have to upgrade ports immediately.  It's just that you can't
> upgrade any single port without re-building everything - for reasons
> that have been spelled out elsewhere in this thread.
> 
> FWIW, the move to versioned symbols should (in theory) remove the
> need to need to do a future complete recompile once you've rebuilt
> all your ports against 7.x.

My laptop has about 1000 ports installed and, when I did the mass
upgrade a week or two ago. I did it a bit differently from most
recommendations.

I deleted all of the directories in /usr/local except etc and a coupe
containing locally built and install software. This really cleans up any
cruft from /usr/local. :-)

Next, I manually installed lang/ruby18 and ports-mgmt/portupgrade and
did a 'portupgrade -afP'. Since the pkgdb was still in place, it knew
which ports had been installed before I nuked /usr/local. I only had to
build one big, time consuming port, jdk16. I also had to re-build about
8 or 9 ports (postfix and several multimedia ports) for local config
reasons.

I ran it over night, starting up at "quitting time", and it finished the
first pass early the next morning. I installed jdk15 from the diablo
package and built jdk16. Then I upgraded the ports which were dependent
on jdk16 (about a dozen) from packages.

All in all, this worked rather well, although issuing all those 'rm -rf
/usr/local//*'s is very disconcerting.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgp429WszLhp5.pgp
Description: PGP signature

Re: Upgrading to 7.0 - stupid requirements

[Peter Jeremy]

On Wed, Mar 19, 2008 at 07:43:25PM +0100, Marko Lerota wrote:
>time from ports because there are only small portion of precompiled 
>packages.

There should be a fairly complete set of packages for 7.0-RELEASE.
There can never be a totally complete set of packages for legal
reasons - the licenses on some ports do not permit them to be packaged.

>This thing should be solved.

Please offer some suggestions on how you would resolve the problem.

>And If I upgrade the OS I dont want to recompile ports for that.

You don't have to upgrade ports immediately.  It's just that you can't
upgrade any single port without re-building everything - for reasons
that have been spelled out elsewhere in this thread.

FWIW, the move to versioned symbols should (in theory) remove the
need to need to do a future complete recompile once you've rebuilt
all your ports against 7.x.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.


pgpOTGxZebB8f.pgp
Description: PGP signature

Re: Upgrading to 7.0 - stupid requirements

[Scott Robbins]

On Wed, Mar 19, 2008 at 03:46:52PM -0400, Kevin K wrote:
> > That said: I do understand what you're saying, and yes, I can see why
> > you would want that.  It does make sense, and it's reasonable.  It's
> > just hard to achieve.  I don't think other mainstream OSes (e.g. Linux)
> > offer this ability either, though.  Am I wrong?
> 
> Redhat's up2date/yum ? I'm not 100% certain though.

RedHat, some Debian versions and others aimed at the server market will
have their precompiled binaries with reasonably sane defaults.  (Or else
with everything, including the kitchen sink, thrown in.)

The downside is that the server based ones, (RH, CentOS, etc.,) are
going to have older versions of packages.  This makes sense of course.
Much of the time, they'll simply concentrate on security updates and
have a 5 year EOL (possibly longer, possibly shorter, but around that.)

Desktop---well, things like Ubuntu and Fedora usually have major
upgrades every 6 months or so.  Fedora at least, recommends doing a
complete reinstall, though usually, updating via their yum package
manager will work.  It doesn't always. 

Arch Linux and some others have a rolling release type thing, where
incremental upgrades take place all the time, usually without major
effect.  They're smaller, and like the BSDs tend to be better at letting
people know--(things similar to our HEADSUP type posts.)  Fedora in
contrast, might make a decision that will break sound for 30 percent of
the users and the only way to find out will be to dig through their
(rather slow) bugzilla, only to find that the developer doesn't consider
it a bug.  (That's not an insult aimed at the developer--they have their
reasons which are often quite logical, but anyway...)


-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Xander: She must be right. We must have some kind of
amnesia.
Buffy: I don't know what that is, but I'm certain I don't have it. I
bathe quite
often.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Oliver Fromme]

Marko Lerota wrote:
 > This thing should be solved. I liked the way that my OS have
 > independance from ports.

Well, they are not really completely independent.
The ports still use libraries from the base OS,
e.g. libc, threading libraries etc.  Please try
to understand the following simple example.

The problem is this:  Program A from ports links
against library B from ports.  Both programm A and
libray B als link against libc.so.6 from the base OS
(FreeBSD 6).

Now you update to FreeBSD 7, but you don't update
all the ports.  Everything still works (even though
FreeBSD has a new libc.so.7), because the old
software uses libc.so.6 from the compat6x port.

BUT ...  As soon as you have to update the old
library B because of a security problem or anything,
you will run into problems:  The new library B will
link against the new libc.so.7, but the old program
A (which uses library B) is still linked against the
libc.do.6 from compat6x.  So when you try to run
program A, it will try to load both libc.so.6 and
libc.so.7 (via library B), which will fail, because
a binary cannot use two different versions of the
same library at once.  So program A stops working.

Of course, rebuilding program A will solve the
problem, so it links to the new libc.so.7, too.
That's easy.  But in practice it is a lot more
complicated, because you have many ports with many
binaries and many libraries, with many dependencies
between them.

You could try to run "pkg_info -R" each time you
update something, so you can make sure to update
all ports dependent on the one you update.  If you
do this every time, everything will continue to
work, but it's tedious, and as soon as you forget
something, you will run into trouble.

Really, the easiest and most reliable way is to
rebuild all ports (or download compiled packages)
and be done with it.

 > So no metter what I do with ports, my OS and his apps will work.

They _will_ work.  The trouble only starts when you
update some of the ports on which other ports depend,
as explained above.

 > If this thing can be solved (I'm not programmer so I don't know) I can
 > donate some amount of $ for development. I think that this would make
 > lots of people happy.

I have to admit I see no way how the problem could
be solved in a different way, I'm afraid.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"C++ is over-complicated nonsense. And Bjorn Shoestrap's book
a danger to public health. I tried reading it once, I was in
recovery for months."
-- Cliff Sarginson
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Brad Pitney]

On Wed, Mar 19, 2008 at 7:46 PM, Kevin K <[EMAIL PROTECTED]> wrote:
> > That said: I do understand what you're saying, and yes, I can see why
>  > you would want that.  It does make sense, and it's reasonable.  It's
>  > just hard to achieve.  I don't think other mainstream OSes (e.g. Linux)
>  > offer this ability either, though.  Am I wrong?
>
>  Redhat's up2date/yum ? I'm not 100% certain though.
>

OpenBSD's pkg_add has an -i option that allows options, their binary
packages are build with various options, also they recommend using
their binary packages as opposed to building your own. Although with
FreeBSD having over 18000 ports, I don't see it as viable given
constraints.

some people are just ungrateful for what they already have, even if
they have options.

Marko, there is nothing stopping you from building binary packages on
another machine with the options YOU want, some ports might not
remember what it is was you specified, well there are work arounds,
just remember /etc/make.conf is just like a Makefile so you could do
something like this:

.if ${.CURDIR:M*/ports}
.if ${.CURDIR:M*/apache22}
WITH_APR_FROM_PORTS=
WITH_MPM=worker
WITH_PGSQL=
WITH_STATIC_SUPPORT=
WITH_SQLITE=
WITH_KQUEUE_SUPPORT=
WITH_THREADS=
.endif
.endif

by the way, it's a suggestion, nothing more. But Works For Me (TM). I
would love to see something like the way pkgsrc handles options in
ports:

PKG_DEFAULT_OPTIONS = ssl pam kerberos acl ads ldap lang-en-GB gssapi
kqueue sasl sqlite apr1 apache22
PKG_DEFAULT_OPTIONS += -debug -mysql -ruby-build-ri-db
PKG_OPTIONS.sudo = -kerberos

>
>
>
>
>
>  ___
>  freebsd-stable@freebsd.org mailing list
>  http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>  To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>



-- 
Best regards,
 Brad
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Chuck Swiger]

On Mar 19, 2008, at 11:43 AM, Marko Lerota wrote:
This thing should be solved. I liked the way that my OS have  
independance
from ports. So no metter what I do with ports, my OS and his apps  
will work.

And If I upgrade the OS I dont want to recompile ports for that.


The traditional mechanism for ensuring that a binary would continue to  
work after an OS upgrade is to statically link in any libraries used,  
which would prevent the problem of upgrading some shared library that  
normally would be dynamically loaded and thus inherit a mixture of  
dependencies.


The main disadvantage of static linking is that you can't update a  
library to fix bugs or whatever without having to relink the program  
the way you could update a shared library; secondarily, dynamic  
linking can reduce the overall system memory requirements for running  
lots of processes which use common shared libraries.


--
-Chuck

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Upgrading to 7.0 - stupid requirements

[Kevin K]

> That said: I do understand what you're saying, and yes, I can see why
> you would want that.  It does make sense, and it's reasonable.  It's
> just hard to achieve.  I don't think other mainstream OSes (e.g. Linux)
> offer this ability either, though.  Am I wrong?

Redhat's up2date/yum ? I'm not 100% certain though.




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Jeremy Chadwick]

On Wed, Mar 19, 2008 at 07:43:25PM +0100, Marko Lerota wrote:
> If you use BSD system only for few apps like PHP/Apache/MySQL it would 
> be easy. But if you have lots of stuff for desktop machine (gnome,xfce etc.) 
> it's very painful, long, and waste of time. (I don't have x386 33MHz CPU) 
> 
> This thing should be solved. I liked the way that my OS have independance
> from ports. So no metter what I do with ports, my OS and his apps will work.
> And If I upgrade the OS I dont want to recompile ports for that.
> If this thing can be solved (I'm not programmer so I don't know) I can
> donate some amount of $ for development. I think that this would make
> lots of people happy.

Am I to understand that you want prebuilt binary packages for PHP which
encapsulate every possible combination of "make config" options?  That's
a bit unreasonable with how the ports framework is built.  That's
something like over a hundred prebuilt packages -- just for PHP.

That said: I do understand what you're saying, and yes, I can see why
you would want that.  It does make sense, and it's reasonable.  It's
just hard to achieve.  I don't think other mainstream OSes (e.g. Linux)
offer this ability either, though.  Am I wrong?

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Marko Lerota]

Kris Kennaway <[EMAIL PROTECTED]> writes:

> Are you connected via a modem or something?  2-3 days to download some
> packages cannot be right if you have a decent internet connection.

No I have 5Mbps link. It's not the link issue. It's the compilation
time from ports because there are only small portion of precompiled 
packages. And some of my apps need special switches like to tell 
PHP to build module for apache. I cant do that just from portupgrade -faP.

If you use BSD system only for few apps like PHP/Apache/MySQL it would 
be easy. But if you have lots of stuff for desktop machine (gnome,xfce etc.) 
it's very painful, long, and waste of time. (I don't have x386 33MHz CPU) 

This thing should be solved. I liked the way that my OS have independance
from ports. So no metter what I do with ports, my OS and his apps will work.
And If I upgrade the OS I dont want to recompile ports for that.
If this thing can be solved (I'm not programmer so I don't know) I can
donate some amount of $ for development. I think that this would make
lots of people happy.

-- 
One cannot sell the earth upon which the people walk
Tacunka Witco 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Vincent Mialon]

Le Wednesday 19 March 2008 17:41:21 Vivek Khera, vous avez écrit :
> On Mar 19, 2008, at 8:46 AM, Michael Grant wrote:
> > My server is live and serving customers.  I can't afford to take the
> > box down for a whole day while I upgrade ports.  Is there any
> > intelligent way to do this?
>
> Here's what you do:
>
> 1) take one server at a time down from the load balancer/worker pool
> 2) upgrade it
> 3) put it back in service
> 4) go to step 1 until all servers are updated.

Why not installing FreeBSD 7 on a spare server or a workstation ? You can 
build your own packages, rsync your confs and test. 

When everything work, delete all packages on the old server. Make a 
freebsd-upgrade install. Install all your previously builded packages and put 
your confs back. The down time should not be too long I gess ?

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Vivek Khera]

On Mar 19, 2008, at 8:46 AM, Michael Grant wrote:

My server is live and serving customers.  I can't afford to take the
box down for a whole day while I upgrade ports.  Is there any
intelligent way to do this?


Here's what you do:

1) take one server at a time down from the load balancer/worker pool
2) upgrade it
3) put it back in service
4) go to step 1 until all servers are updated.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Markiyan Kushnir]

It's amazing -- I also did my recent 6.3->7.0 exactly this way. Running 
it as a desktop, WindowMaker, some of gnu apps. kde is at hand mostly 
for a couple of applications, but it works ok either.


My case is much simpler, but I feel that it's worth of considering 
alternatives to portupgrade. I learned much from using portupgrade.


Thanks,
Markiyan


Oliver Fromme wrote:

Hello Marko,

I'm very sorry that you have trouble updating your FreeBSD
installation, but there are very good technical reasons to
update your packages, as others have already explained in
detail (i.e. library conflicts).

When I updated my home workstation from FreeBSD 6 to 7,
I used the opportunity to clean up my installed packages,
which was long overdue anyway.

First I saved the output from "pkg_info" in a file.  Then
I edited it and removed everything that I don't need.
There was lots of superfluous crap in it, like ports that
I installed once out of curiosity but never continued to
use them, and ports that were installed as a dependency
once but aren't required anymore because the dependent
software is long gone.

Then I did "pkg_delete \*", checked for left-overs in
/usr/local because not everything was removed cleanly,
and then installed the ports from my text file again.
I chose to compile from ports instead of installing
precompiled packages because the machine is fairly fast
(if you have a slow machine, installing packages will
be much faster, of course).

It certainly went a lot quicker than if I had blindly
updated all ports without cleaning up.  And now all of
my installed packages are guaranteed to be fresh and
up to date, and I only have the stuff on my harddisk
that I really need.

Really, such situations where you should update all of
your packages is the best opportunity to clean up the
mess that has accumulated on your disk in a long time.
I recommend that everyone considers doing that, too,
instead of blindly running portupgrade.  Of course,
the latter would work, too, but it takes longer and
will rather add to the mess instead of cleaning it. ;-)

Best regards
   Oliver



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Jeremy Chadwick]

On Wed, Mar 19, 2008 at 01:46:07PM +0100, Michael Grant wrote:
> My server is live and serving customers.  I can't afford to take the
> box down for a whole day while I upgrade ports.  Is there any
> intelligent way to do this?

The ways people have given you are proper *and* intelligent.  I think
the piece of information you're not understanding (or haven't been
given?) is that library semantics change.  That doesn't just mean
library version numbers -- it means actual API functionality changes.

> For example, could I do everything on a second disk while running the
> live system on the first disk?  For example using a chroot so it
> thinks it's
> 
> For example, might this work?
> 
> 1) upgrade system in the canonical way:
> # make buildworld
> # make buildkernel
> # make installkernel
> # reboot
> # mergemaster -p
> # make installworld
> # mergemaster
> # reboot

Assuming after "reboot" you include boot into single user: yep, correct.
Follow the procedure documented in /usr/src/Makefile to a tee.  Do not
deviate from it unless you know *exactly* the risks of doing so.  :-)

By the way, all of the above guarantees downtime.  You seem to be of the
"I must achieve Five Nines" mentality, so I'll point you to why Five
Nines is absurd: http://en.wikipedia.org/wiki/Myth_of_the_nines

> 2) make sure misc/compat6x is installed

You're asking for trouble right here.  I've discussed in a previous
thread (if you want me to dig it up I can) the dangers of using the
compatXx packages.  You can:

* End up with dual libraries in your ld.so path, which can result
  in functions of the same name being loaded, which is a problem
  because...
* Function semantics/API differences exist between RELENG_7 and
  RELENG_6, 6 and 5, 5 and 4, 4 and 3 -- but function names remain
  the same.
* Library innards change.  Best example?  libkvm.  These are so
  major that an entries goes into /usr/src/UPDATING when the semantics
  change.  People who don't follow the proper upgrade procedure get
  amusing results: "top doesn't work, it spits out some weird error!"
  "why is ps broken?!?" etc.
* "Library nightmare" syndrome, which is the UNIX equivalent of
  Windows' "DLL Hell".  Some program on the machine attempts to
  link to a library called "libapemans.so.4", and you have two
  versions of it: one for 6, and one for 7.  Uh oh!

How do you avoid these problems?

You use software that you have the source for, and rebuild that software
from the source.  You then guarantee (assuming compatXx isn't installed)
that the software links to a proper library, works with proper API
functionality (or else it won't compile/link properly), and you retain a
clean library tree.

In the case of packages, they're also OK.  Just be sure to use ones for
the OS release you're using; don't go pkg_add'ing packages from RELENG_5
on your RELENG_7 box, for example.  :-)  Remember: you have the source.

Do you have programs from commercial vendors who do not give you source,
which relies upon RELENG_6?  If so, you should consider *not* migrating
from RELENG_6, and instead getting your vendor to build their software
on RELENG_7!  Work with them, help them, test with them.

> 3) on a second disk or in a directory somewhere like /new
> a) nullfs mount read-only all the things one needs inside a chroot to
> work except /usr/local
> b) create a writable /usr/local, /usr/X11R6, /compat/linux and /var/db
> in the chroot
> 
> 4) then for each package installed, install it within the chroot

I don't see how this is going to work.  You would need to copy a TON of
files from /usr/lib, /libexec, /usr/libexec, and other places into your
chroot tree before anything will work.  You'll also have to use chflags
to deal with files that're schg.

Additionally, if you're installing **packages**, why are you bothering
with the chroot aspect?  This should be a VERY quick task -- no
compiling needed, since they're all binary.  It WILL NOT take an entire
day.  I'd say 30 minutes -- tops.

All that said...

I'm a hosting provider myself, not just of websites, but of servers and
of rack space as well.  I've done it since 1993, using Linux from 1993
to 1997.

We have users who are lax ("oh, the server was down for 2 hours?  No
biggie"), and those who are so incredibly anal that I consider
terminating them ("The site was offline for 15 seconds when you reloaded
Apache, why?!").  We also have commercial customers who demand *prior*
notice of when we do things, and trust our ability/judgement.

In the case of all clientel, we tell them when there's going to be
downtime (unless otherwise unexpected), and give them a general estimate
of the downtime when it's going to happen.  They have come to accept
that, regardless of how long.  Customers are actually not too bad as
long as you communicate with them honestly and openly.

We have multiple servers.  Some run RELENG_7, others RELENG_6.  We've
gone through the pain of RELENG_3 --> 4 --> 5 --> 6 --> 7 over the
years, and definitely found what

Re: Upgrading to 7.0 - stupid requirements

[Michael Grant]

My server is live and serving customers.  I can't afford to take the
box down for a whole day while I upgrade ports.  Is there any
intelligent way to do this?

For example, could I do everything on a second disk while running the
live system on the first disk?  For example using a chroot so it
thinks it's

For example, might this work?

1) upgrade system in the canonical way:
# make buildworld
# make buildkernel
# make installkernel
# reboot
# mergemaster -p
# make installworld
# mergemaster
# reboot

2) make sure misc/compat6x is installed

3) on a second disk or in a directory somewhere like /new
a) nullfs mount read-only all the things one needs inside a chroot to
work except /usr/local
b) create a writable /usr/local, /usr/X11R6, /compat/linux and /var/db
in the chroot

4) then for each package installed, install it within the chroot

5) when all that's done, drop into single-user mode and move
/usr/local, /usr/X11R6, /compat/linux, and /var/db/pkg to the real
system (saving the old ones)

6) reboot

Warning, I have never tried this.

-Mike

On Wed, Mar 19, 2008 at 11:47 AM, Oliver Fromme <[EMAIL PROTECTED]> wrote:
> Hello Marko,
>
>  I'm very sorry that you have trouble updating your FreeBSD
>  installation, but there are very good technical reasons to
>  update your packages, as others have already explained in
>  detail (i.e. library conflicts).
>
>  When I updated my home workstation from FreeBSD 6 to 7,
>  I used the opportunity to clean up my installed packages,
>  which was long overdue anyway.
>
>  First I saved the output from "pkg_info" in a file.  Then
>  I edited it and removed everything that I don't need.
>  There was lots of superfluous crap in it, like ports that
>  I installed once out of curiosity but never continued to
>  use them, and ports that were installed as a dependency
>  once but aren't required anymore because the dependent
>  software is long gone.
>
>  Then I did "pkg_delete \*", checked for left-overs in
>  /usr/local because not everything was removed cleanly,
>  and then installed the ports from my text file again.
>  I chose to compile from ports instead of installing
>  precompiled packages because the machine is fairly fast
>  (if you have a slow machine, installing packages will
>  be much faster, of course).
>
>  It certainly went a lot quicker than if I had blindly
>  updated all ports without cleaning up.  And now all of
>  my installed packages are guaranteed to be fresh and
>  up to date, and I only have the stuff on my harddisk
>  that I really need.
>
>  Really, such situations where you should update all of
>  your packages is the best opportunity to clean up the
>  mess that has accumulated on your disk in a long time.
>  I recommend that everyone considers doing that, too,
>  instead of blindly running portupgrade.  Of course,
>  the latter would work, too, but it takes longer and
>  will rather add to the mess instead of cleaning it. ;-)
>
>  Best regards
>Oliver
>
>  --
>  Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
>  Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
>  secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
>  chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
>
>  FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
>
>  Python is executable pseudocode.  Perl is executable line noise.
>
>
> ___
>  freebsd-stable@freebsd.org mailing list
>  http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>  To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Oliver Fromme]

Hello Marko,

I'm very sorry that you have trouble updating your FreeBSD
installation, but there are very good technical reasons to
update your packages, as others have already explained in
detail (i.e. library conflicts).

When I updated my home workstation from FreeBSD 6 to 7,
I used the opportunity to clean up my installed packages,
which was long overdue anyway.

First I saved the output from "pkg_info" in a file.  Then
I edited it and removed everything that I don't need.
There was lots of superfluous crap in it, like ports that
I installed once out of curiosity but never continued to
use them, and ports that were installed as a dependency
once but aren't required anymore because the dependent
software is long gone.

Then I did "pkg_delete \*", checked for left-overs in
/usr/local because not everything was removed cleanly,
and then installed the ports from my text file again.
I chose to compile from ports instead of installing
precompiled packages because the machine is fairly fast
(if you have a slow machine, installing packages will
be much faster, of course).

It certainly went a lot quicker than if I had blindly
updated all ports without cleaning up.  And now all of
my installed packages are guaranteed to be fresh and
up to date, and I only have the stuff on my harddisk
that I really need.

Really, such situations where you should update all of
your packages is the best opportunity to clean up the
mess that has accumulated on your disk in a long time.
I recommend that everyone considers doing that, too,
instead of blindly running portupgrade.  Of course,
the latter would work, too, but it takes longer and
will rather add to the mess instead of cleaning it. ;-)

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

Python is executable pseudocode.  Perl is executable line noise.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Angelo Turetta]

Kris Kennaway wrote:

Kevin Oberman wrote:


Or, is the system failing to retrieve the packages and failing over to
building the ports? This would take a long time!

I always tee the output of portupgrade to a file so, if it dies in the
middle, it's pretty easy to pick up where it left off and not re-build
everything twice.


Yes, also I am pretty sure that if you rerun portupgrade -faP a second 
time it will reuse the cached packages it downloaded last time, if they 
are not out of date.


This may be true if you have created the /usr/ports/packages folder 
(which doesn't exist by default)
Anyway, if the packages are not found, they will be built from sources. 
In this case adding -p will save the packages for the next run (so 
portupgrade -faPp).


Angelo.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Ian Smith]

On Tue, 18 Mar 2008, Kris Kennaway wrote:
 > Kevin Oberman wrote:
 > 
 > > Or, is the system failing to retrieve the packages and failing over to
 > > building the ports? This would take a long time!
 > > 
 > > I always tee the output of portupgrade to a file so, if it dies in the
 > > middle, it's pretty easy to pick up where it left off and not re-build
 > > everything twice.

Yep, or use script(1).  Amazing what you pick up from the handbook :)

 > Yes, also I am pretty sure that if you rerun portupgrade -faP a second 
 > time it will reuse the cached packages it downloaded last time, if they 
 > are not out of date.

I've sometimes had some trouble with some of the mirrors not always
having [all] the packages needed, and have had to shop around a bit. 

Running portupgrade -anPP will pick up at least all top-level packages
available first, and you can check your script output (and what's in
/usr/ports/packages) to be sure you've got X, KDE and other Big Stuff.

Then even the bandwidth- and/or CPU-impaired are good to go with -faP. 

cheers, Ian

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Vincent Barus]

On Tue, Mar 18, 2008 at 8:21 PM, Marko Lerota <[EMAIL PROTECTED]> wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
>
>  >> Then the servers. Why should I reinstall all my databases and such?
>  >> I always
>  >> liked that FreeBSD base (OS) is separated from packages. And no
>  >> matter what I do with the packages, my OS will always work. I don't
>  >> want dependency
>  >> hell like in Linux. Now you are telling me that my database might not work
>  >> after upgrade to a new version. Is that it?
>  >
>  > First, try to relax.
>
>  Sorry, but I'm pissed off now, not relax any more.
>
>
>  > portupgrade -faP requests to reinstall everything from precompiled
>  > packages.  It will only fall back to compiling them locally if the
>  > package is unavailable (e.g. for legal reasons).
>
>  It passed two days from portupgrade -faP, and it didn't finished yet.
>  To be worse, I have to do it again because the PC had to be rebooted.
>  So in the next 2-3 days I can sit with my PC and wait with him to
>  finish the upgrade. It will be three days because of [EMAIL 
> PROTECTED]@[EMAIL PROTECTED]
>  And I have to pray the god that I don't have the power loss.
>  Now apache and acroread doesn't work any more and I'm afraid that
>  I'll find some other stuff that don't work too.
>
>  So can anyone tell me this is not stupid??? Reinstalling all
>  applications because of upgrade? This can be called new
>  installation. Not upgrade.
>
>  Now I'm thinking that It would be much easier that I backup my files,
>  databases and other stuff and do fresh installation. But why
>  So I can do the same thing when 8_0 comes out?
>
>  This is the worst thing that I found about FreeBSD for now.
>  This have to be changed or fixed somehow, because the upgrade
>  is not possible if you have lots of ports installed, and
>  certainly can't be called upgrade!
>
>
>  --
>  One cannot sell the earth upon which the people walk
> Tacunka Witco
>  ___
>
>
> freebsd-stable@freebsd.org mailing list
>  http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>  To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>

Hi Marko,

you can always use the -w flag of portupgrade if interrupted it while
upgrading the installed ports:

w
--noclean
Do not "make clean" before each build. See the -c option above.

If you start the portupgrade again without -w then it will use -c by
default which means all your "inbuildproccess" ports are gone.
I don't know if -w is the clean way to resume from an interrupted
portupgrade, but i never had problems with it.
Well, ok you mustn't install any other port before you resume your
portupgrade that could confuse your system :)

The more clean and easy way to do a upgrade of your ports after
switching to another major release (I do it this way everytime):

#pkg_delete -fa  <--- is much faster than pkg_deinstall

Then i get my Ports with the -P flag of portinstall. A few days ago I
did it this way after I jumped from 7 Release to 7 Stable.
It took me about three hours to get my x11-wm/xfce4, x11/xorg (yes the
complete xorg) and some other tools I need to work because the biggest
part of this ports were available as prebuild pkgs.

Try it this way,

Vincent
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Kris Kennaway]

Kevin Oberman wrote:


Or, is the system failing to retrieve the packages and failing over to
building the ports? This would take a long time!

I always tee the output of portupgrade to a file so, if it dies in the
middle, it's pretty easy to pick up where it left off and not re-build
everything twice.


Yes, also I am pretty sure that if you rerun portupgrade -faP a second 
time it will reuse the cached packages it downloaded last time, if they 
are not out of date.


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Kevin Oberman]

> Date: Tue, 18 Mar 2008 21:22:52 +0100
> From: Kris Kennaway <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
> Marko Lerota wrote:
> > Kris Kennaway <[EMAIL PROTECTED]> writes:
> > 
> >>> Then the servers. Why should I reinstall all my databases and such?
> >>> I always
> >>> liked that FreeBSD base (OS) is separated from packages. And no
> >>> matter what I do with the packages, my OS will always work. I don't
> >>> want dependency
> >>> hell like in Linux. Now you are telling me that my database might not work
> >>> after upgrade to a new version. Is that it?
> >> First, try to relax.
> > 
> > Sorry, but I'm pissed off now, not relax any more.
> > 
> >> portupgrade -faP requests to reinstall everything from precompiled
> >> packages.  It will only fall back to compiling them locally if the
> >> package is unavailable (e.g. for legal reasons).
> > 
> > It passed two days from portupgrade -faP, and it didn't finished yet.
> > To be worse, I have to do it again because the PC had to be rebooted.
> > So in the next 2-3 days I can sit with my PC and wait with him to 
> > finish the upgrade. It will be three days because of [EMAIL 
> > PROTECTED]@[EMAIL PROTECTED]
> 
> Are you connected via a modem or something?  2-3 days to download some 
> packages cannot be right if you have a decent internet connection.
> 
> > And I have to pray the god that I don't have the power loss.
> > Now apache and acroread doesn't work any more and I'm afraid that 
> > I'll find some other stuff that don't work too.
> > 
> > So can anyone tell me this is not stupid??? Reinstalling all 
> > applications because of upgrade? This can be called new 
> > installation. Not upgrade.
> > 
> > Now I'm thinking that It would be much easier that I backup my files,
> > databases and other stuff and do fresh installation. But why
> > So I can do the same thing when 8_0 comes out? 
> > 
> > This is the worst thing that I found about FreeBSD for now.
> > This have to be changed or fixed somehow, because the upgrade
> > is not possible if you have lots of ports installed, and 
> > certainly can't be called upgrade!
> > 
> 
> I'm sorry you feel that way, but you haven't understood the explanations 
> that you have been given already.

Or, is the system failing to retrieve the packages and failing over to
building the ports? This would take a long time!

I always tee the output of portupgrade to a file so, if it dies in the
middle, it's pretty easy to pick up where it left off and not re-build
everything twice.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgpbDGB2RWHNb.pgp
Description: PGP signature

Re: Upgrading to 7.0 - stupid requirements

[Kris Kennaway]

Marko Lerota wrote:

Kris Kennaway <[EMAIL PROTECTED]> writes:


Then the servers. Why should I reinstall all my databases and such?
I always
liked that FreeBSD base (OS) is separated from packages. And no
matter what I do with the packages, my OS will always work. I don't
want dependency
hell like in Linux. Now you are telling me that my database might not work
after upgrade to a new version. Is that it?

First, try to relax.


Sorry, but I'm pissed off now, not relax any more.


portupgrade -faP requests to reinstall everything from precompiled
packages.  It will only fall back to compiling them locally if the
package is unavailable (e.g. for legal reasons).


It passed two days from portupgrade -faP, and it didn't finished yet.
To be worse, I have to do it again because the PC had to be rebooted.
So in the next 2-3 days I can sit with my PC and wait with him to 
finish the upgrade. It will be three days because of [EMAIL PROTECTED]@[EMAIL PROTECTED]


Are you connected via a modem or something?  2-3 days to download some 
packages cannot be right if you have a decent internet connection.



And I have to pray the god that I don't have the power loss.
Now apache and acroread doesn't work any more and I'm afraid that 
I'll find some other stuff that don't work too.


So can anyone tell me this is not stupid??? Reinstalling all 
applications because of upgrade? This can be called new 
installation. Not upgrade.


Now I'm thinking that It would be much easier that I backup my files,
databases and other stuff and do fresh installation. But why
So I can do the same thing when 8_0 comes out? 


This is the worst thing that I found about FreeBSD for now.
This have to be changed or fixed somehow, because the upgrade
is not possible if you have lots of ports installed, and 
certainly can't be called upgrade!




I'm sorry you feel that way, but you haven't understood the explanations 
that you have been given already.


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Marko Lerota]

Kris Kennaway <[EMAIL PROTECTED]> writes:

>> Then the servers. Why should I reinstall all my databases and such?
>> I always
>> liked that FreeBSD base (OS) is separated from packages. And no
>> matter what I do with the packages, my OS will always work. I don't
>> want dependency
>> hell like in Linux. Now you are telling me that my database might not work
>> after upgrade to a new version. Is that it?
>
> First, try to relax.

Sorry, but I'm pissed off now, not relax any more.

> portupgrade -faP requests to reinstall everything from precompiled
> packages.  It will only fall back to compiling them locally if the
> package is unavailable (e.g. for legal reasons).

It passed two days from portupgrade -faP, and it didn't finished yet.
To be worse, I have to do it again because the PC had to be rebooted.
So in the next 2-3 days I can sit with my PC and wait with him to 
finish the upgrade. It will be three days because of [EMAIL PROTECTED]@[EMAIL 
PROTECTED]
And I have to pray the god that I don't have the power loss.
Now apache and acroread doesn't work any more and I'm afraid that 
I'll find some other stuff that don't work too.

So can anyone tell me this is not stupid??? Reinstalling all 
applications because of upgrade? This can be called new 
installation. Not upgrade.

Now I'm thinking that It would be much easier that I backup my files,
databases and other stuff and do fresh installation. But why
So I can do the same thing when 8_0 comes out? 

This is the worst thing that I found about FreeBSD for now.
This have to be changed or fixed somehow, because the upgrade
is not possible if you have lots of ports installed, and 
certainly can't be called upgrade!

-- 
One cannot sell the earth upon which the people walk
Tacunka Witco 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Chris H.]

Quoting Kris Kennaway <[EMAIL PROTECTED]>:


Chris H. wrote:


While not a recommended substitution for "good housekeeping". I thought it
worth mentioning:
LIBMAP.CONF(5)
http://www.freebsd.org/cgi/man.cgi?query=libmap.conf&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE&format=html


This can be used safely sometimes, but it is dangerous when 
attempting to work around library version issues.  In general, 
library version numbers change because the libraries are 
incompatible, and if you force the issue with libmap (or its cruder 
cousin, ln -s) you will begin to enumerate the ways in which they are 
not compatible when your application crashes or misbehaves.


Using libmap should not be thought of as a solution unless you know 
what you are doing and can verify that it is safe on a case by case 
basis.


This may sound like pedantic advice, but I have dealt with many 
mailing list users who are all up in arms about "how crap the ports 
collection has become..nothing works any more...freebsd is 
dying...and *mumble mumble* when I botched an upgrade a few months 
ago I symlinked all the missing libraries to new versions...don't do 
that you say?  But that cannot possibly be related...oh wait it was, 
okbye."


I quite agree, and wasn't trying to advocate it's use for this sort of
thing - see; not a recommended substitution for "good housekeeping". :)
But thought it might be worth mentioning just the same.

--Chris H

P.S. I think pedantic frequently gets a bad rap. ;)



Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"





--
panic: kernel trap (ignored)



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Andrew Kolchoogin]

Sat, 29/02/2008 at 10:08 +0100, Dick Hoogendijk writes:

> > No one is forcing you to upgrade.
> Head in the sand reaction.
Nope.

> I think the guy is right.
> The upgrade proces and constant rebuilding of ports made me switch in
> the end after years of using freeBSD. My computer is fast, but I want
> to use it for someting useful iso compiling and compiling and..
You were not forced to.

All of your installed software will work fine if you install 6.x
compatibility libraries unless a piece of software is inherently
system-dependant.

Generally speaking, OpenOffice.org will work fine, and lm_sensors
MIGHT, but it is not guaranteed to.

As of any major version upgrade of FreeBSD. :)
-- 
Yours
Andrew Kolchoogin.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Kris Kennaway]

Chris H. wrote:


While not a recommended substitution for "good housekeeping". I thought it
worth mentioning:
LIBMAP.CONF(5)
http://www.freebsd.org/cgi/man.cgi?query=libmap.conf&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE&format=html 


This can be used safely sometimes, but it is dangerous when attempting 
to work around library version issues.  In general, library version 
numbers change because the libraries are incompatible, and if you force 
the issue with libmap (or its cruder cousin, ln -s) you will begin to 
enumerate the ways in which they are not compatible when your 
application crashes or misbehaves.


Using libmap should not be thought of as a solution unless you know what 
you are doing and can verify that it is safe on a case by case basis.


This may sound like pedantic advice, but I have dealt with many mailing 
list users who are all up in arms about "how crap the ports collection 
has become..nothing works any more...freebsd is dying...and *mumble 
mumble* when I botched an upgrade a few months ago I symlinked all the 
missing libraries to new versions...don't do that you say?  But that 
cannot possibly be related...oh wait it was, okbye."


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Kris Kennaway]

Dick Hoogendijk wrote:

On Thu, 28 Feb 2008 18:43:20 -0500
"Kevin K" <[EMAIL PROTECTED]> wrote:


No one is forcing you to upgrade.


Head in the sand reaction.
I think the guy is right.
The upgrade proces and constant rebuilding of ports made me switch in
the end after years of using freeBSD. My computer is fast, but I want
to use it for someting useful iso compiling and compiling and..


Uh, we have had precompiled package support for over a decade now.  Did 
you really not know about it?!


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Dick Hoogendijk]

On Thu, 28 Feb 2008 18:43:20 -0500
"Kevin K" <[EMAIL PROTECTED]> wrote:

> No one is forcing you to upgrade.

Head in the sand reaction.
I think the guy is right.
The upgrade proces and constant rebuilding of ports made me switch in
the end after years of using freeBSD. My computer is fast, but I want
to use it for someting useful iso compiling and compiling and..

-- 
Dick Hoogendijk -- PGP/GnuPG key: 01D2433D
++ http://nagual.nl/ + SunOS sxde 01/08 ++
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Chris H.]

Quoting Marko Lerota <[EMAIL PROTECTED]>:


In http://www.freebsd.org/releases/7.0R/announce.html says

Updating Existing Systems


An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes
a major version upgrade, so no matter which method you use to update
an older system you should reinstall any ports you have installed on
the machine. This will avoid binaries becoming linked to inconsistent
sets of libraries when future port upgrades rebuild one port but not
others that link to it. This can be done with:


# portupgrade -faP

etc...

Why!!! Do you know how much time I have to spend with my PC to reinstall
all of this programs from ports? Only openoffice takes one day! And where
is Gnome and such...There must be other way...I would not reinstall my
packages ;)

Then the servers. Why should I reinstall all my databases and such? I always
liked that FreeBSD base (OS) is separated from packages. And no matter what I
do with the packages, my OS will always work. I don't want dependency
hell like in Linux. Now you are telling me that my database might not work
after upgrade to a new version. Is that it?


While not a recommended substitution for "good housekeeping". I thought it
worth mentioning:
LIBMAP.CONF(5)
http://www.freebsd.org/cgi/man.cgi?query=libmap.conf&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE&format=html


--Chris H



--
One cannot sell the earth upon which the people walk
Tacunka Witco
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"





--
panic: kernel trap (ignored)



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Mark Andrews]

> 
> > Marko Lerota wrote:
> > > In http://www.freebsd.org/releases/7.0R/announce.html says 
> > > 
> > > Updating Existing Systems
> > > 
> > > > An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes 
> > > > a major version upgrade, so no matter which method you use to update 
> > > > an older system you should reinstall any ports you have installed on 
> > > > the machine. This will avoid binaries becoming linked to inconsistent 
> > > > sets of libraries when future port upgrades rebuild one port but not 
> > > > others that link to it. This can be done with:
> > > 
> > > # portupgrade -faP
> > > 
> > > etc...
> > > 
> > > Why!!!
> > 
> > If you never rebuild any ports at all after upgrading to a new major
> > version, then your ports should all continue to work as long as they can
> > find the old libraries they need.  However, once you rebuild a port, it
> > will link to new libraries, and may also link to other libraries that
> > continue to be linked to the old libraries.  You may end up with a binary
> > being linked against libc.so.6 and libc.so.7, which will not work.
> > 
> > > Then the servers. Why should I reinstall all my databases and such? I 
> > > always
> > > liked that FreeBSD base (OS) is separated from packages. And no matter 
> > > what I
>  
> > > do with the packages, my OS will always work. I don't want dependency
> > > hell like in Linux. Now you are telling me that my database might not work
> > > after upgrade to a new version. Is that it?
> > 
> > Ports that depend on other ports are vulnerable to this problem.  Ports
> > that only require base libraries are not.  The more ports a port depends
> > on, the more likely you are to run into problems if you don't rebuild all
> > ports to begin with.
> > 
> > So, if you don't ever rebuild any of your ports at all, everything should
> > still work until you finally do rebuild a port.  At that point, if that port
> > doesn't depend on other ports and only links to base libraries, you'll
> > still be fine.  Once you rebuild a port that depends on other ports,
> > things may break if you don't force a rebuild of every port that port
> > depends on.
> 
>   Running "portupgrade -nrR " repeated until
>stabilised used to also work for just-in-time
>   upgrades like this.  Unfortunately "portupgrade -nrR" no
>   longer reports packages that won't be upgraded.  There are
>   no longer any "-" entries in the output.
> 
>   I need to see what "portupgrade -nrRf" does before reporting
>   this.

For example if I was to upgrade firefox I'd have to upgrade
548 of the 582 packages on this machine.

Mark

getlist:
#!/bin/sh -f
sed -e '/Depends on:/d' \
-e '/Information for/d' \
-e '/Required by:/d' \
-e '/^$/d' \
-e 's/Dependency://' \
-e 's/ //g' |
sort -u

% pkg_info -rR "*fox*" | ./getlist | wc
 100 1001665
% pkg_info -rR "*fox*" | ./getlist | xargs pkg_info -rR | ./getlist | wc
 467 4678435
% pkg_info -rR "*fox*" | ./getlist | xargs pkg_info -rR | ./getlist | xargs 
pkg_info -rR | ./getlist | xargs pkg_info -rR | ./getlist | wc  547 
5479780
drugs:9.4.x 14:03 {2701} % pkg_info -rR "*fox*" | ./getlist | xargs pkg_info 
-rR | ./getlist | xargs pkg_info -rR | ./getlist | xargs pkg_info -rR | 
./getlist | xargs pkg_info -rR | ./getlist | wc
 548 5489793
% pkg_info -rR "*fox*" | ./getlist | xargs pkg_info -rR | ./getlist | xargs 
pkg_info -rR | ./getlist | xargs pkg_info -rR | ./getlist | xargs pkg_info -rR 
| ./getlist | xargs pkg_info -rR | ./getlist | wc
 548 5489793
% pkg_info | wc
 5823869   34258
% 
  
> > The paragraph you quoted above attempts to avoid that breakage and the
> > mailing list questions that ensue, by forcing a rebuild of all ports to
> > begin with.
> > 
> > -- 
> > Skip
> > ___
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Mark Andrews]

> Marko Lerota wrote:
> > In http://www.freebsd.org/releases/7.0R/announce.html says 
> > 
> > Updating Existing Systems
> > 
> > > An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes 
> > > a major version upgrade, so no matter which method you use to update 
> > > an older system you should reinstall any ports you have installed on 
> > > the machine. This will avoid binaries becoming linked to inconsistent 
> > > sets of libraries when future port upgrades rebuild one port but not 
> > > others that link to it. This can be done with:
> > 
> > # portupgrade -faP
> > 
> > etc...
> > 
> > Why!!!
> 
> If you never rebuild any ports at all after upgrading to a new major
> version, then your ports should all continue to work as long as they can
> find the old libraries they need.  However, once you rebuild a port, it
> will link to new libraries, and may also link to other libraries that
> continue to be linked to the old libraries.  You may end up with a binary
> being linked against libc.so.6 and libc.so.7, which will not work.
> 
> > Then the servers. Why should I reinstall all my databases and such? I always
> > liked that FreeBSD base (OS) is separated from packages. And no matter what 
> > I 
> > do with the packages, my OS will always work. I don't want dependency
> > hell like in Linux. Now you are telling me that my database might not work
> > after upgrade to a new version. Is that it?
> 
> Ports that depend on other ports are vulnerable to this problem.  Ports
> that only require base libraries are not.  The more ports a port depends
> on, the more likely you are to run into problems if you don't rebuild all
> ports to begin with.
> 
> So, if you don't ever rebuild any of your ports at all, everything should
> still work until you finally do rebuild a port.  At that point, if that port
> doesn't depend on other ports and only links to base libraries, you'll
> still be fine.  Once you rebuild a port that depends on other ports,
> things may break if you don't force a rebuild of every port that port
> depends on.

Running "portupgrade -nrR " repeated until
 stabilised used to also work for just-in-time
upgrades like this.  Unfortunately "portupgrade -nrR" no
longer reports packages that won't be upgraded.  There are
no longer any "-" entries in the output.

I need to see what "portupgrade -nrRf" does before reporting
this.
 
> The paragraph you quoted above attempts to avoid that breakage and the
> mailing list questions that ensue, by forcing a rebuild of all ports to
> begin with.
> 
> -- 
> Skip
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Kris Kennaway]

Bakul Shah wrote:

As I've tried to explain, the difficulty is when you start recompiling 
parts of them, e.g. a shared library used by other ports.


Understood.

Hmm... If prior to any recompile such a shared lib was copied
to a compat dir (based on the most recent shared lib *it*
depends on), programs relying on it would continue working.


Tools like portupgrade do save copies of old libraries in 
/usr/local/lib/compat (which helps in other upgrade scenarios), but it 
doesn't help in the OS upgrade case because the old and new shared port 
libraries have the same version and cannot be distinguished 
automatically by the linker.


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Bakul Shah]

On Fri, 29 Feb 2008 01:57:32 +0100 Kris Kennaway <[EMAIL PROTECTED]>  wrote:
> Bakul Shah wrote:
> > On Fri, 29 Feb 2008 00:54:55 +0100 Kris Kennaway <[EMAIL PROTECTED]>  wrote:
> >> portupgrade -faP requests to reinstall everything from precompiled 
> >> packages.  It will only fall back to compiling them locally if the 
> >> package is unavailable (e.g. for legal reasons).
> >>
> >> Second, the reason for this requirement is explained in the 
> >> announcement.  In fact, it has *always* been required to recompile ports 
> >> when moving to a new major release of FreeBSD, for guaranteed correct 
> >> operation when some of the ports are updated later on.
> > 
> > Er... Can't one run old binaries after installing one or more
> > of usr/ports/misc/compat-[3456]x -- that has not changed, has
> > it?
> 
> No, it has not.

Excellent! I was getting worried a bit :-)

> As I've tried to explain, the difficulty is when you start recompiling 
> parts of them, e.g. a shared library used by other ports.

Understood.

Hmm... If prior to any recompile such a shared lib was copied
to a compat dir (based on the most recent shared lib *it*
depends on), programs relying on it would continue working.

Thanks for the explanation.  
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Skip Ford]

Marko Lerota wrote:
> In http://www.freebsd.org/releases/7.0R/announce.html says 
> 
> Updating Existing Systems
> 
> > An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes 
> > a major version upgrade, so no matter which method you use to update 
> > an older system you should reinstall any ports you have installed on 
> > the machine. This will avoid binaries becoming linked to inconsistent 
> > sets of libraries when future port upgrades rebuild one port but not 
> > others that link to it. This can be done with:
> 
> # portupgrade -faP
> 
> etc...
> 
> Why!!!

If you never rebuild any ports at all after upgrading to a new major
version, then your ports should all continue to work as long as they can
find the old libraries they need.  However, once you rebuild a port, it
will link to new libraries, and may also link to other libraries that
continue to be linked to the old libraries.  You may end up with a binary
being linked against libc.so.6 and libc.so.7, which will not work.

> Then the servers. Why should I reinstall all my databases and such? I always
> liked that FreeBSD base (OS) is separated from packages. And no matter what I 
> do with the packages, my OS will always work. I don't want dependency
> hell like in Linux. Now you are telling me that my database might not work
> after upgrade to a new version. Is that it?

Ports that depend on other ports are vulnerable to this problem.  Ports
that only require base libraries are not.  The more ports a port depends
on, the more likely you are to run into problems if you don't rebuild all
ports to begin with.

So, if you don't ever rebuild any of your ports at all, everything should
still work until you finally do rebuild a port.  At that point, if that port
doesn't depend on other ports and only links to base libraries, you'll
still be fine.  Once you rebuild a port that depends on other ports,
things may break if you don't force a rebuild of every port that port
depends on.

The paragraph you quoted above attempts to avoid that breakage and the
mailing list questions that ensue, by forcing a rebuild of all ports to
begin with.

-- 
Skip
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Kris Kennaway]

Bakul Shah wrote:

On Fri, 29 Feb 2008 00:54:55 +0100 Kris Kennaway <[EMAIL PROTECTED]>  wrote:
portupgrade -faP requests to reinstall everything from precompiled 
packages.  It will only fall back to compiling them locally if the 
package is unavailable (e.g. for legal reasons).


Second, the reason for this requirement is explained in the 
announcement.  In fact, it has *always* been required to recompile ports 
when moving to a new major release of FreeBSD, for guaranteed correct 
operation when some of the ports are updated later on.


Er... Can't one run old binaries after installing one or more
of usr/ports/misc/compat-[3456]x -- that has not changed, has
it?


No, it has not.

As I've tried to explain, the difficulty is when you start recompiling 
parts of them, e.g. a shared library used by other ports.


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Bakul Shah]

On Fri, 29 Feb 2008 00:54:55 +0100 Kris Kennaway <[EMAIL PROTECTED]>  wrote:
> portupgrade -faP requests to reinstall everything from precompiled 
> packages.  It will only fall back to compiling them locally if the 
> package is unavailable (e.g. for legal reasons).
> 
> Second, the reason for this requirement is explained in the 
> announcement.  In fact, it has *always* been required to recompile ports 
> when moving to a new major release of FreeBSD, for guaranteed correct 
> operation when some of the ports are updated later on.

Er... Can't one run old binaries after installing one or more
of usr/ports/misc/compat-[3456]x -- that has not changed, has
it?

I agree that people *should* recompile but it is not always
possible or convenient and in such cases the compat libraries
are a good crutch. In face one strong point of freebsd has
been (or was) backward compatibility.

> This is not FreeBSD-specific advice.  It is true on any operating system 
> when the underlying set of libraries changes in an incompatible way. 
> However, on FreeBSD this *only* happens betweeen version branches.

Almost all commercial OSes provide some degree of backward
compatibility; some do much better (such as IBM & SGI).
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Kris Kennaway]

Edwin Groothuis wrote:

On Fri, Feb 29, 2008 at 01:03:31AM +0100, Kris Kennaway wrote:

Edwin Groothuis wrote:

On Fri, Feb 29, 2008 at 12:08:22AM +0100, Marko Lerota wrote:
In http://www.freebsd.org/releases/7.0R/announce.html says 


Updating Existing Systems

An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes 
a major version upgrade, so no matter which method you use to update 
an older system you should reinstall any ports you have installed on 

Should, not must. Use misc/compat6x if you don't want to do this,
but that doesn't work for things which look in the kernel (sysutils/lsof
for example)

No: must, not should.

If you don't do this, then when you update e.g. only some of the gnome 
libraries without recompiling all of gnome, then your gnome binaries 
will have libraries linked to libc.so.6 and libc.so.7, and to 
libkse.so.2 as well as libthr.so.3, and this is a guaranteed runtime 
crash because these are mutually inconsistent sets of libraries.


He wanted independance of the base OS and the installed software.
He didn't want to upgrade his software because of software version
incompatibilies.

That was the scenario where this advice was given on.


OK, it is true that if users do not plan to upgrade self-contained 
subsets of their installed 6.x software, then those subsets will 
continue to function indefinitely using the compat6x libraries.


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Edwin Groothuis]

On Fri, Feb 29, 2008 at 01:03:31AM +0100, Kris Kennaway wrote:
> Edwin Groothuis wrote:
> >On Fri, Feb 29, 2008 at 12:08:22AM +0100, Marko Lerota wrote:
> >>In http://www.freebsd.org/releases/7.0R/announce.html says 
> >>
> >>Updating Existing Systems
> >>
> >>>An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes 
> >>>a major version upgrade, so no matter which method you use to update 
> >>>an older system you should reinstall any ports you have installed on 
> >
> >Should, not must. Use misc/compat6x if you don't want to do this,
> >but that doesn't work for things which look in the kernel (sysutils/lsof
> >for example)
> 
> No: must, not should.
> 
> If you don't do this, then when you update e.g. only some of the gnome 
> libraries without recompiling all of gnome, then your gnome binaries 
> will have libraries linked to libc.so.6 and libc.so.7, and to 
> libkse.so.2 as well as libthr.so.3, and this is a guaranteed runtime 
> crash because these are mutually inconsistent sets of libraries.

He wanted independance of the base OS and the installed software.
He didn't want to upgrade his software because of software version
incompatibilies.

That was the scenario where this advice was given on.

Edwin

-- 
Edwin Groothuis  |Personal website: http://www.mavetju.org
[EMAIL PROTECTED]|  Weblog: http://www.mavetju.org/weblog/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Kris Kennaway]

Edwin Groothuis wrote:

On Fri, Feb 29, 2008 at 12:08:22AM +0100, Marko Lerota wrote:
In http://www.freebsd.org/releases/7.0R/announce.html says 


Updating Existing Systems

An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes 
a major version upgrade, so no matter which method you use to update 
an older system you should reinstall any ports you have installed on 


Should, not must. Use misc/compat6x if you don't want to do this,
but that doesn't work for things which look in the kernel (sysutils/lsof
for example)


No: must, not should.

If you don't do this, then when you update e.g. only some of the gnome 
libraries without recompiling all of gnome, then your gnome binaries 
will have libraries linked to libc.so.6 and libc.so.7, and to 
libkse.so.2 as well as libthr.so.3, and this is a guaranteed runtime 
crash because these are mutually inconsistent sets of libraries.


The mailing list archives have many examples of people who ran into this 
in the past.


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Steven Hartland]

Nothing to stop you using packages if you so wish.

- Original Message - 
From: "Marko Lerota" <[EMAIL PROTECTED]>

# portupgrade -faP

etc...

Why!!! Do you know how much time I have to spend with my PC to reinstall
all of this programs from ports? Only openoffice takes one day! And where 
is Gnome and such...There must be other way...I would not reinstall my 
packages ;)

...


This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to [EMAIL PROTECTED]

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marko Lerota wrote:
> In http://www.freebsd.org/releases/7.0R/announce.html says 
> 
> Updating Existing Systems
> 
>> An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes 
>> a major version upgrade, so no matter which method you use to update 
>> an older system you should reinstall any ports you have installed on 
>> the machine. This will avoid binaries becoming linked to inconsistent 
>> sets of libraries when future port upgrades rebuild one port but not 
>> others that link to it. This can be done with:
> 
> # portupgrade -faP
> 
> etc...
> 
> Why!!! Do you know how much time I have to spend with my PC to reinstall
> all of this programs from ports? Only openoffice takes one day! And where 
> is Gnome and such...There must be other way...I would not reinstall my 
> packages ;)
> 
> Then the servers. Why should I reinstall all my databases and such? I always
> liked that FreeBSD base (OS) is separated from packages. And no matter what I 
> do with the packages, my OS will always work. I don't want dependency
> hell like in Linux. Now you are telling me that my database might not work
> after upgrade to a new version. Is that it?

With '-P' I think portupgrade would use packages where possible.
Granted, it's a big PITA to install big beasts like OpenOffice, etc. :(

One suggestion: install misc/compat6x.  The rebuild-everything  is just
an suggestion which will avoid problems caused by binary
incompatibility, like some shared objects wants libc.so.6 and some else
wants libc.so.7 which will end up with big chaos.  Beginning from
FreeBSD 7.0, we have introduced the versioned symbols which may
eliminate the need of the massive rebuild in the future...

Cheers,
- --
Xin LI <[EMAIL PROTECTED]>  http://www.delphij.net/
FreeBSD - The Power to Serve!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHx0rFi+vbBBjt66ARAu0DAKC78/+duFcICQehw+V8YS3jTLTxKACfap87
914qnITBN6QinVyVry2FBfc=
=2lXm
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Kris Kennaway]

Marko Lerota wrote:
In http://www.freebsd.org/releases/7.0R/announce.html says 


Updating Existing Systems

An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes 
a major version upgrade, so no matter which method you use to update 
an older system you should reinstall any ports you have installed on 
the machine. This will avoid binaries becoming linked to inconsistent 
sets of libraries when future port upgrades rebuild one port but not 
others that link to it. This can be done with:


# portupgrade -faP

etc...

Why!!! Do you know how much time I have to spend with my PC to reinstall
all of this programs from ports? Only openoffice takes one day! And where 
is Gnome and such...There must be other way...I would not reinstall my 
packages ;)


Then the servers. Why should I reinstall all my databases and such? I always
liked that FreeBSD base (OS) is separated from packages. And no matter what I 
do with the packages, my OS will always work. I don't want dependency

hell like in Linux. Now you are telling me that my database might not work
after upgrade to a new version. Is that it?


First, try to relax.

portupgrade -faP requests to reinstall everything from precompiled 
packages.  It will only fall back to compiling them locally if the 
package is unavailable (e.g. for legal reasons).


Second, the reason for this requirement is explained in the 
announcement.  In fact, it has *always* been required to recompile ports 
when moving to a new major release of FreeBSD, for guaranteed correct 
operation when some of the ports are updated later on.


This is not FreeBSD-specific advice.  It is true on any operating system 
when the underlying set of libraries changes in an incompatible way. 
However, on FreeBSD this *only* happens betweeen version branches.


Sometimes you can get away without the full recompile (this was more 
often true in the past), but thesedays so many ports do things like 
dynamic loading of shared libraries that it is effectively mandatory advice.


Feel free to ignore the advice if you continue to feel outraged by it, 
but it will not be our fault when your ports suddenly stop working 
properly after your subsequent port upgrades.


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Edwin Groothuis]

On Fri, Feb 29, 2008 at 12:08:22AM +0100, Marko Lerota wrote:
> In http://www.freebsd.org/releases/7.0R/announce.html says 
> 
> Updating Existing Systems
> 
> > An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes 
> > a major version upgrade, so no matter which method you use to update 
> > an older system you should reinstall any ports you have installed on 

Should, not must. Use misc/compat6x if you don't want to do this,
but that doesn't work for things which look in the kernel (sysutils/lsof
for example)

Also, it doesn't say that you don't need to upgrade your ports, you
need to reinstall them.

Problem resolved by carefully reading.

Edwin

-- 
Edwin Groothuis  |Personal website: http://www.mavetju.org
[EMAIL PROTECTED]|  Weblog: http://www.mavetju.org/weblog/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upgrading to 7.0 - stupid requirements

[Chuck Swiger]

On Feb 28, 2008, at 3:08 PM, Marko Lerota wrote:

In http://www.freebsd.org/releases/7.0R/announce.html says

Updating Existing Systems

An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes
a major version upgrade, so no matter which method you use to update
an older system you should reinstall any ports you have installed on
the machine. This will avoid binaries becoming linked to inconsistent
sets of libraries when future port upgrades rebuild one port but not
others that link to it. This can be done with:


# portupgrade -faP

etc...

Why!!!


The comment above tells you: "This will avoid binaries becoming linked  
to inconsistent sets of libraries when future port upgrades rebuild  
one port but not others that link to it."



Do you know how much time I have to spend with my PC to reinstall
all of this programs from ports? Only openoffice takes one day! And  
where

is Gnome and such...There must be other way...I would not reinstall my
packages ;)


Sure, you could stick with 6.3 for quite some time.

Then the servers. Why should I reinstall all my databases and such?  
I always
liked that FreeBSD base (OS) is separated from packages. And no  
matter what I

do with the packages, my OS will always work. I don't want dependency
hell like in Linux. Now you are telling me that my database might  
not work

after upgrade to a new version. Is that it?


Not exactly.  The 6.x binaries will continue to work just fine under  
7.0, so long as you don't recompile any of the libraries they are  
using.  However, as soon as you start upgrading anything, you will end  
up with programs trying to pull in the 6.x and 7.x version of libc  
etc, and that will cause problems.


Note that the portupgrade command given above will try to download  
precompiled binaries where available, rather than requiring you to  
compile everything locally.


--
-Chuck

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Upgrading to 7.0 - stupid requirements

[Kevin K]

No one is forcing you to upgrade.


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-freebsd-
> [EMAIL PROTECTED] On Behalf Of Marko Lerota
> Sent: Thursday, February 28, 2008 6:08 PM
> To: freebsd-stable@freebsd.org
> Subject: Upgrading to 7.0 - stupid requirements
> 
> In http://www.freebsd.org/releases/7.0R/announce.html says
> 
> Updating Existing Systems
> 
> > An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes
> > a major version upgrade, so no matter which method you use to update
> > an older system you should reinstall any ports you have installed on
> > the machine. This will avoid binaries becoming linked to inconsistent
> > sets of libraries when future port upgrades rebuild one port but not
> > others that link to it. This can be done with:
> 
> # portupgrade -faP
> 
> etc...
> 
> Why!!! Do you know how much time I have to spend with my PC to
> reinstall
> all of this programs from ports? Only openoffice takes one day! And
> where
> is Gnome and such...There must be other way...I would not reinstall my
> packages ;)
> 
> Then the servers. Why should I reinstall all my databases and such? I
> always
> liked that FreeBSD base (OS) is separated from packages. And no matter
> what I
> do with the packages, my OS will always work. I don't want dependency
> hell like in Linux. Now you are telling me that my database might not
> work
> after upgrade to a new version. Is that it?
> 
> --
> One cannot sell the earth upon which the people walk
>   Tacunka Witco
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-
> [EMAIL PROTECTED]"
> 
> __ NOD32 2910 (20080228) Information __
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"