Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Jun 2004 21:26:42 +0400
From:      Sergey Zaharchenko <doublef@tele-kom.ru>
To:        Robert Huff <roberthuff@rcn.com>
Cc:        questions@freebsd.org
Subject:   Re: Updating source code manually
Message-ID:  <20040628172641.GB2963@shark.localdomain>
In-Reply-To: <16608.13888.194802.955936@jerusalem.litteratus.org>
References:  <BAY15-F11fWM5nWGsRw00004a38@hotmail.com> <20040628134639.GA5699@shark.localdomain> <16608.13888.194802.955936@jerusalem.litteratus.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--TakKZr9L6Hm6aLOc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 28, 2004 at 11:16:16AM -0400,
 Robert Huff probably wrote:
>=20
> Sergey Zaharchenko writes:
>=20
> >  Just a minute. You shouldn't portupgrade KDE when KDE is running,
> >  but you should be able to run `make' to build everything while
> >  KDE is running, shut down KDE and `portupgrade -w' afterwards
> >  (which will use the binaries built by `make' and install them,
> >  taking seriously less time than the original `make') and restart
> >  KDE. At least that's how it would with an ordinary port.
>=20
> 	One of the two of us is confused about this.
> 	As I understand it:

> 	A) Running "make build" but not "make install" doesn't really
> solve the "installing while running" issue.  Sure, it won't install
> for that port, but it will build-and-install for every port upstream
> ...

I see. You are talking abiout ABI mismatch. I dug up a portion of your
earlier post:

>       Let's say KDE uses libfoo.1.5.so, which is actually v1.5.7.
> You upgrade something, which upgrades libfoo.1.5.so to v1.5.8.  The
> kernel (unaware of the change) reloads part of the file and restarts
> execution at a particular address.  Will that address valid code?

When a file is open by a process, even if you unlink it and replace it
with another one, the original file will stay on disk until the last
file handle referencing it is closed. I assume that holds true for
libraries too. So, EXISTING processes aren't screwed. But, when a NEW
process is created, it references the NEW shared library, and if their
ABI's don't match --- BOOM!:) That was just a correction.

I was under the impression that the OP already had KDE (and thus all
`father' ports) installed and up-to-date, and only wanted to patch a
file. That would mean there would be 0 upstream ports rebuilt, or am I
mistaken? Maybe my post looks like stating it's a universal approach. It
isn't. Sorry I didn't mention it.

But if the OP doesn't have KDE up-to-date, he could `downgrade' his
ports tree to match his packages (reducing the problem to the previous
one). Of course that's only possible if the patch applies to the
`downgraded' KDE too. He will still have to build (not-up-to-date) KDE,
but this should escape ABI worries, as in fact no other changes will be
made.

> 	B) ... unless you're suggesting starting at the top of the
> dependency tree and doing build-but-don't-install by hand for every
> component in order.  I consider this severely impractical; it also ...

The ABI problem isn't solved by your B) approach, which will only build
`father' ports but still install `grandfather' ports.

> 	C) ... won't work with portupgrade unless one uses the "w" option.

Please read more carefully. I mentioned '-w'.

--=20
DoubleF
"When I was crossing the border into Canada, they asked if I had any
firearms with me.  I said, `Well, what do you need?'"
		-- Steven Wright

--TakKZr9L6Hm6aLOc
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFA4FTRwo7hT/9lVdwRAm9NAJ4l3rV0IpKDWa5RYQn+fZEHMKET9QCfcmLU
j0p0X4slXRuQcgdXjqwRw1E=
=yaSa
-----END PGP SIGNATURE-----

--TakKZr9L6Hm6aLOc--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040628172641.GB2963>