HEADS UP: xorg upgrade plans
Kris Kennaway
--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi all,
After many months of hard work (mostly by flz@, as well as others) we
are approaching readiness of the xorg 7.2 upgrade. Because this is a
huge and disruptive change, we're going to approach it very carefully.
The current plan is the following:
1) Tag ports with PRE_XORG_7 and freeze the ports tree. This will
give a stable base from which to prepare the final patchset in the
secondary git repository that has been used for xorg integration.
This will probably happen in the next day or two; sorry for the short
notice but I don't want to artificially delay any longer (this has
already been delayed for months by other reasons).
2) Final prep work in git repository. We need a day or two to confirm
the upgrade method for users. Unfortunately testing has exposed a
critical deficiency in portupgrade so 'portupgrade -a' will not be
enough to give a working upgrade, and some pre-upgrade steps will be
required. Also a post-upgrade step is required to deal with merging
remaining files from /usr/X11R6 into /usr/local.
3) Once the proposed upgrade method is in place, we will publish a
tarball of the prepared ports tree and request that *all* our ports
developers test the upgrade on their own machines before it is
committed to CVS. There are many things that can go wrong and we need
to make sure that the upgrade goes as smoothly as possible for our
less technical users. In particular all ports committers are expected
to participate in this process of eating our own dogfood :)
4) Once a suitable number of success reports (e.g. 50) are received
and all reported issues are resolved, we'll proceed with importing
into CVS.
5) CVS will stay frozen for a period to be evaluated (probably another
couple of weeks) to deal with the inevitable remaining fallout as
users encounter yet more problems with the upgrade.
Thanks for your support, and get ready for xorg 7.2! :-)
Kris
--oyUTqETQ0mS9luUI
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFGOOcvWry0BWjoQKURAhPHAKDkcLzAe8ryr7aOE9Xv1LYADlqfWACgg6Z8
jZZCAKSetagIvzDmeBo2OpQ=
=spYZ
-----END PGP SIGNATURE-----
--oyUTqETQ0mS9luUI--
Kris Kennaway
--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, May 02, 2007 at 02:40:26PM -0500, Stephen Montgomery-Smith wrote:
>=20
>=20
> On Wed, 2 May 2007, Kris Kennaway wrote:
>=20
> >Hi all,
> >
> >After many months of hard work (mostly by flz@, as well as others) we
> >are approaching readiness of the xorg 7.2 upgrade. Because this is a
> >huge and disruptive change, we're going to approach it very carefully.
>=20
> I tried X 7.2 about a week ago, and I can report some minor problems.
>=20
> First, "pkg_delete -a" took far too long. X7.2 has so many dependencies,=
=20
> that I sense that it is beginning to overload the ports structure. My=20
> guess is that "pkg_delete -a" spends a huge amount of time just checking=
=20
> out all the dependencies before it even starts.
To some extent this is true. It's not something we can fix now though.
> Secondly, X7.2 as I tried it wouldn't "startx" if some other login had=20
> created a .Xauthority file. While "rm .Xauthority" solved the problem=20
> completely, I don't think this is user friendly.
I think I ran into this once a while back, I don't know what is the
correct solution.
Kris
--yrj/dFKFPuw6o+aM
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFGOOndWry0BWjoQKURAmmZAJ4z/QRa/Blluz8Ej7gdIZjUTDPjPwCfaHDo
SpSWbNnxuuqfsjBfcKZfX10=
=mRlI
-----END PGP SIGNATURE-----
--yrj/dFKFPuw6o+aM--
Stephen Montgomery-Smith
On Wed, 2 May 2007, Kris Kennaway wrote:
> On Wed, May 02, 2007 at 02:40:26PM -0500, Stephen Montgomery-Smith wrote:
>
>> Secondly, X7.2 as I tried it wouldn't "startx" if some other login had
>> created a .Xauthority file. While "rm .Xauthority" solved the problem
>> completely, I don't think this is user friendly.
>
> I think I ran into this once a while back, I don't know what is the
> correct solution.
Perhaps you could put in some kind of "setenv XAUTHORITY .Xlocalauthority"
in a script somewhere.
Actually this one can bite you quite badly. If you are running X, and
then you login from somehwere else, and then go back to the X session,
then suddenly all your X commands like xterm will completely stop working.
It can be really disconcerting if you don't know what caused it, and I can
see a large number of help messages being generated on the various
bulletin boards.
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
Stephen Montgomery-Smith
On Wed, 2 May 2007, Martin Tournoij wrote:
> On Wed 02 May 2007 14:05, Stephen Montgomery-Smith wrote:
>>
>>
>> On Wed, 2 May 2007, Kris Kennaway wrote:
>>
>>> Hi all,
>>>
>>> After many months of hard work (mostly by flz@, as well as others) we
>>> are approaching readiness of the xorg 7.2 upgrade. Because this is a
>>> huge and disruptive change, we're going to approach it very carefully.
>>
>> I tried X 7.2 about a week ago, and I can report some minor problems.
>>
>> First, "pkg_delete -a" took far too long. X7.2 has so many dependencies, that I sense that it is beginning to overload the ports structure.
>> My guess is that "pkg_delete -a" spends a huge amount of time just checking out all the dependencies before it even starts.
>>
>> Secondly, X7.2 as I tried it wouldn't "startx" if some other login had created a .Xauthority file. While "rm .Xauthority" solved the problem
>> completely, I don't think this is user friendly.
>>
>> But I might be a little out of sate, and all this has since been fixed.
>>
>> Stephen
>
> Doesn't this do the same as pkg_delete -a:
> rm -r /var/db/pkg /usr/local /usr/X11R6
>
> The main difference is that pkg_delete checks the file's checksums,
> and leaves files with changed checksums alone.
>
Yes. And indeed this is more or less what I did (I had various config
files in /usr/local/etc that I didn't want deleted). But this is most
definitely not a user friendly solution!
Kris Kennaway
> On Wed, 2007-05-02 at 15:43 -0400, Kris Kennaway wrote:
> > On Wed, May 02, 2007 at 02:40:26PM -0500, Stephen Montgomery-Smith wrote:
> > >
> > >
> > > On Wed, 2 May 2007, Kris Kennaway wrote:
> > >
> > > >Hi all,
> > > >
> > > >After many months of hard work (mostly by flz@, as well as others) we
> > > >are approaching readiness of the xorg 7.2 upgrade. Because this is a
> > > >huge and disruptive change, we're going to approach it very carefully.
> > >
> > > I tried X 7.2 about a week ago, and I can report some minor problems.
> > >
>
> the time of either the move to /usr/local or the ruby18 update (they
> happened pretty close together for me) portupgrade -na seems to have
> broken for me. It just hangs there forever, seemingly doing something in
> the background and never actually starts checking for updated ports.
> Tried rebuilding INDEX, INDEX.db, and pkgdb.db to no avail... Once I let
> it go overnight and the process died with an Illegal Instruction
> signal...
One of the effects of portupgrade -a using the wrong upgrade order is
that is possible to introduce cycles into the dependency graph (A
depends on B, B depends on A, where I have seen A = xorg-libraries and
B = libXft). In my case it was pkg_create and a cycle in the
+REQUIRED_BY lists (pkg_create looped for an hour between these two
ports but eventually gave up and proceeded).
It is possible that portupgrade might get itself into a similar state
somehow. pkgdb -L might fix it for you.
Kris
Martin Tournoij
>
>
> On Wed, 2 May 2007, Kris Kennaway wrote:
>
> >Hi all,
> >
> >After many months of hard work (mostly by flz@, as well as others) we
> >are approaching readiness of the xorg 7.2 upgrade. Because this is a
> >huge and disruptive change, we're going to approach it very carefully.
>
> I tried X 7.2 about a week ago, and I can report some minor problems.
>
> My guess is that "pkg_delete -a" spends a huge amount of time just checking out all the dependencies before it even starts.
>
> Secondly, X7.2 as I tried it wouldn't "startx" if some other login had created a .Xauthority file. While "rm .Xauthority" solved the problem
> completely, I don't think this is user friendly.
>
> But I might be a little out of sate, and all this has since been fixed.
>
> Stephen
Doesn't this do the same as pkg_delete -a:
rm -r /var/db/pkg /usr/local /usr/X11R6
The main difference is that pkg_delete checks the file's checksums,
and leaves files with changed checksums alone.
Gerald Pfeifer
> process of eating our own dogfood :)
Our marketing folks educated me to use the phrase "drinking our own
champagne" instead. :)
> 5) CVS will stay frozen for a period to be evaluated (probably another
> couple of weeks) to deal with the inevitable remaining fallout as
> users encounter yet more problems with the upgrade.
Does this freeze apply to the whole ports tree, or only (relatively
directly) affected parts of the tree? For example, does this also
apply to lang/gccXY?
Gerald
--
Gerald (Jerry) Pfeifer ger...@pfeifer.com http://www.pfeifer.com/gerald/
Coleman Kane
> On Wed, May 02, 2007 at 02:40:26PM -0500, Stephen Montgomery-Smith wrote:
> >
> >
> >
> > >
> > >After many months of hard work (mostly by flz@, as well as others) we
> > >are approaching readiness of the xorg 7.2 upgrade. Because this is a
> > >huge and disruptive change, we're going to approach it very carefully.
> >
> > I tried X 7.2 about a week ago, and I can report some minor problems.
> >
I've been following the xorg 7.2 tree for some time, and recently around
the time of either the move to /usr/local or the ruby18 update (they
happened pretty close together for me) portupgrade -na seems to have
broken for me. It just hangs there forever, seemingly doing something in
the background and never actually starts checking for updated ports.
Tried rebuilding INDEX, INDEX.db, and pkgdb.db to no avail... Once I let
it go overnight and the process died with an Illegal Instruction
signal...
> > First, "pkg_delete -a" took far too long. X7.2 has so many dependencies,
> > that I sense that it is beginning to overload the ports structure. My
> > guess is that "pkg_delete -a" spends a huge amount of time just checking
> > out all the dependencies before it even starts.
>
> To some extent this is true. It's not something we can fix now though.
>
> > Secondly, X7.2 as I tried it wouldn't "startx" if some other login had
> > created a .Xauthority file. While "rm .Xauthority" solved the problem
> > completely, I don't think this is user friendly.
>
> I think I ran into this once a while back, I don't know what is the
> correct solution.
>
> Kris
--
Coleman Kane
Kris Kennaway
> On Wed, 2 May 2007, Kris Kennaway wrote:
> > process of eating our own dogfood :)
>
> Our marketing folks educated me to use the phrase "drinking our own
> champagne" instead. :)
;-)
> > 5) CVS will stay frozen for a period to be evaluated (probably another
> > couple of weeks) to deal with the inevitable remaining fallout as
> > users encounter yet more problems with the upgrade.
>
> Does this freeze apply to the whole ports tree, or only (relatively
> directly) affected parts of the tree? For example, does this also
> apply to lang/gccXY?
It will apply to everything. It will be basically the same procedure
we usually use for a release cycle, since this event is easily
comparable in scope (probably bigger in fact). The good news is that
if we all jump in to help, the freeze will be over sooner.
Kris
Mark Linimon
> Does this freeze apply to the whole ports tree, or only (relatively
> directly) affected parts of the tree?
The latter is basically most of the tree :-)
mcl
Edwin Groothuis
> 3) Once the proposed upgrade method is in place, we will publish a
> tarball of the prepared ports tree and request that *all* our ports
> developers test the upgrade on their own machines before it is
> committed to CVS. There are many things that can go wrong and we need
> to make sure that the upgrade goes as smoothly as possible for our
> to participate in this process of eating our own dogfood :)
You're talking about the software which gets installed and configured
only once on my machine (that is when it is removed from the box),
being fiddled with for days to get it working in 1280x1024 in 16bpp
(because 24bpp only works in 1024x768), caused me hundreds of hangs
and reboots because I enter the wrong values in some obscure register
somewhere and cause frightened looks of my wife and son when I come
outside my study because the computer is fsck()ing again after an
unexpected hang?
You are asking a lot of me :-)
Edwin
--
Edwin Groothuis | Personal website: http://www.mavetju.org
ed...@mavetju.org | Weblog: http://www.mavetju.org/weblog/
Kris Kennaway
--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, May 02, 2007 at 03:31:59PM -0400, Kris Kennaway wrote:
> Hi all,
>=20
> After many months of hard work (mostly by flz@, as well as others) we
> are approaching readiness of the xorg 7.2 upgrade. Because this is a
> huge and disruptive change, we're going to approach it very carefully.
> The current plan is the following:
>=20
> 1) Tag ports with PRE_XORG_7 and freeze the ports tree. This will
> give a stable base from which to prepare the final patchset in the
> secondary git repository that has been used for xorg integration.
> This will probably happen in the next day or two; sorry for the short
> notice but I don't want to artificially delay any longer (this has
> already been delayed for months by other reasons).
The freeze will begin at 0400 UTC on 04 May, i.e. a little over 24
hours from now.
Kris
--9amGYk9869ThD9tj
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFGOUqiWry0BWjoQKURAkC+AJ9qWtfPAOpOnRsogqagxhZI25APHgCg5bVD
sv54UI24Iu4XALoldXG1vWU=
=0mZO
-----END PGP SIGNATURE-----
--9amGYk9869ThD9tj--
mal content
Hello.
Why is FreeBSD using /usr/local instead of /usr/X11R7?
thanks,
MC
[LoN]Kamikaze
>> /usr/local
>
> Hello.
>
> Why is FreeBSD using /usr/local instead of /usr/X11R7?
>
> thanks,
> MC
A version dependant directory structure hasn't been a good idea in the first place. No one was really able to tell weather to put a port into /usr/X11R6 or /usr/local anyway.
Kris Kennaway
> >/usr/local
>
> Hello.
>
> Why is FreeBSD using /usr/local instead of /usr/X11R7?
/usr/local is the new de facto standard, AFAIK no-one is using
/usr/X11R7.
Kris
mal content
> On Thu, May 03, 2007 at 05:43:47PM +0100, mal content wrote:
> > >/usr/local
> >
> > Hello.
> >
> > Why is FreeBSD using /usr/local instead of /usr/X11R7?
>
> /usr/local is the new de facto standard, AFAIK no-one is using
> /usr/X11R7.
>
> Kris
Oh, OK.
thanks,
MC
Danny Pansters
> mal content wrote:
> >> /usr/local
> >
> > Hello.
> >
> > Why is FreeBSD using /usr/local instead of /usr/X11R7?
> >
> > MC
>
> A version dependant directory structure hasn't been a good idea in the
> first place. No one was really able to tell weather to put a port into
> /usr/X11R6 or /usr/local anyway.
And it's virtually impossible to make a clean pkg-plist if a port/pkg needs to
put stuff in *both* LOCALBASE and X11BASE. Let alone make it PREFIX safe (you
have to choose either as default and cwd to the other halfway the plist).
/usr/X11R6 was a long standing bug about to be fixed once and for all. IIRC it
originated from fixed paths in the old XFree. It won't be missed or
mourned :)
Dan
Robert Huff
> /usr/X11R6 was a long standing bug about to be fixed once and for
> all. IIRC it originated from fixed paths in the old XFree. It
> won't be missed or mourned :)
While I understand why this is going to happen, I've been of
the opinion it ought to be retained with contents limited to the
installed X Windows distribution.
Robert Huff
Coleman Kane
> Danny Pansters writes:
>
> > /usr/X11R6 was a long standing bug about to be fixed once and for
> > all. IIRC it originated from fixed paths in the old XFree. It
> > won't be missed or mourned :)
>
> While I understand why this is going to happen, I've been of
> the opinion it ought to be retained with contents limited to the
> installed X Windows distribution.
>
>
> Robert Huff
This move was also already done on a number of Linux distros...
--
Coleman
Doug Barton
> Hi all,
>
> are approaching readiness of the xorg 7.2 upgrade. Because this is a
> huge and disruptive change, we're going to approach it very carefully.
Good news that this is moving forward! Congrats to all involved.
> The current plan is the following:
>
> 2) Final prep work in git repository. We need a day or two to confirm
> the upgrade method for users. Unfortunately testing has exposed a
> critical deficiency in portupgrade so 'portupgrade -a' will not be
> enough to give a working upgrade, and some pre-upgrade steps will be
> required.
Has portmaster been evaluated as an upgrade tool? I'm in a better
position atm to be able to address any deficiencies if that will help
speed this along.
> Also a post-upgrade step is required to deal with merging
> remaining files from /usr/X11R6 into /usr/local.
>
> 3) Once the proposed upgrade method is in place, we will publish a
> tarball of the prepared ports tree and request that *all* our ports
> developers test the upgrade on their own machines before it is
> committed to CVS. There are many things that can go wrong and we need
> to make sure that the upgrade goes as smoothly as possible for our
> less technical users. In particular all ports committers are expected
> to participate in this process of eating our own dogfood :)
Any updates on a timeline for this?
> 4) Once a suitable number of success reports (e.g. 50) are received
> and all reported issues are resolved, we'll proceed with importing
> into CVS.
>
> 5) CVS will stay frozen for a period to be evaluated (probably another
> couple of weeks) to deal with the inevitable remaining fallout as
> users encounter yet more problems with the upgrade.
Do you intend to keep the entire ports tree frozen for weeks? Perhaps
I misunderstand?
Doug
--
This .signature sanitized for your protection
Kris Kennaway
> Kris Kennaway wrote:
> >Hi all,
> >
> >After many months of hard work (mostly by flz@, as well as others) we
> >are approaching readiness of the xorg 7.2 upgrade. Because this is a
> >huge and disruptive change, we're going to approach it very carefully.
>
> Good news that this is moving forward! Congrats to all involved.
>
> >The current plan is the following:
> >
> >2) Final prep work in git repository. We need a day or two to confirm
> >the upgrade method for users. Unfortunately testing has exposed a
> >critical deficiency in portupgrade so 'portupgrade -a' will not be
> >enough to give a working upgrade, and some pre-upgrade steps will be
> >required.
>
> Has portmaster been evaluated as an upgrade tool? I'm in a better
> position atm to be able to address any deficiencies if that will help
> speed this along.
No, at a minimum I am not comfortable recommending its use until it
saves old shared libraries across updates (I sent you email about this
a while ago), which is a vital safety and robustness mechanism.
> >Also a post-upgrade step is required to deal with merging
> >remaining files from /usr/X11R6 into /usr/local.
> >
> >3) Once the proposed upgrade method is in place, we will publish a
> >tarball of the prepared ports tree and request that *all* our ports
> >developers test the upgrade on their own machines before it is
> >committed to CVS. There are many things that can go wrong and we need
> >to make sure that the upgrade goes as smoothly as possible for our
> >less technical users. In particular all ports committers are expected
> >to participate in this process of eating our own dogfood :)
>
> Any updates on a timeline for this?
Some time this week
>
> >4) Once a suitable number of success reports (e.g. 50) are received
> >and all reported issues are resolved, we'll proceed with importing
> >into CVS.
> >
> >5) CVS will stay frozen for a period to be evaluated (probably another
> >couple of weeks) to deal with the inevitable remaining fallout as
> >users encounter yet more problems with the upgrade.
>
> Do you intend to keep the entire ports tree frozen for weeks? Perhaps
> I misunderstand?
Yes, that is the plan. This is an "all hands" event, and keeping it
frozen is the best way to focus developers onto those tasks.
Kris
Doug Barton
> On Mon, May 07, 2007 at 11:38:46AM -0700, Doug Barton wrote:
>> Kris Kennaway wrote:
>>> Hi all,
>>>
>>> After many months of hard work (mostly by flz@, as well as others) we
>>> are approaching readiness of the xorg 7.2 upgrade. Because this is a
>>> huge and disruptive change, we're going to approach it very carefully.
>> Good news that this is moving forward! Congrats to all involved.
>>
>>> The current plan is the following:
>>>
>>> 2) Final prep work in git repository. We need a day or two to confirm
>>> the upgrade method for users. Unfortunately testing has exposed a
>>> critical deficiency in portupgrade so 'portupgrade -a' will not be
>>> enough to give a working upgrade, and some pre-upgrade steps will be
>>> required.
>> Has portmaster been evaluated as an upgrade tool? I'm in a better
>> position atm to be able to address any deficiencies if that will help
>> speed this along.
>
> No, at a minimum I am not comfortable recommending its use until it
> saves old shared libraries across updates (I sent you email about this
> a while ago), which is a vital safety and robustness mechanism.
Ok, no worries then. I have no plans to add that feature at this time,
partly because there has been no user demand for it, and mostly
because I don't like the idea. I recognize however that reasonable
minds may differ on that topic.
Doug
--
This .signature sanitized for your protection
Jeremy Messenger
=
wrote:
> On Mon, May 07, 2007 at 11:38:46AM -0700, Doug Barton wrote:
>> Kris Kennaway wrote:
>> >Hi all,
>> >
>> >After many months of hard work (mostly by flz@, as well as others) w=
e
>> >are approaching readiness of the xorg 7.2 upgrade. Because this is =
a
>> >huge and disruptive change, we're going to approach it very carefull=
y.
>>
>> Good news that this is moving forward! Congrats to all involved.
>>
>> >The current plan is the following:
>> >
>> >2) Final prep work in git repository. We need a day or two to confi=
rm
>> >the upgrade method for users. Unfortunately testing has exposed a
>> >critical deficiency in portupgrade so 'portupgrade -a' will not be
>> >enough to give a working upgrade, and some pre-upgrade steps will be=
>> >required.
>>
>> Has portmaster been evaluated as an upgrade tool? I'm in a better
>> position atm to be able to address any deficiencies if that will help=
>> speed this along.
My plan is to run 'portmaster -r pkg-config\*'. I think it should do fin=
e =
as 'portmaster -r' will do it in order very well.
> No, at a minimum I am not comfortable recommending its use until it
> saves old shared libraries across updates (I sent you email about this=
> a while ago), which is a vital safety and robustness mechanism.
I am one of people that dislike this and it is not required to get build=
=
function. ;-) I think this option should be disable by default, because =
=
put stuff in lib/compat/pkg hides the problems. Also:
http://www.freebsd.org/gnome/docs/faq2.html#q2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[...]
Prevent two versions of the same library.
A common source of build failures is the existence of multiple versions =
of =
the same library. This can happen if you have two different versions of =
a =
port installed, or can even happen through normal portupgrade use. You c=
an =
back up the libraries in /usr/local/lib/compat/pkg and remove them, and =
=
then run portupgrade -u -rf pkg-config. This will force a rebuild of all=
=
GNOME-related apps (and a fair number of other apps) without retaining o=
ld =
versions of libraries in /usr/local/lib/compat/pkg.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Cheers,
Mezz
>> >Also a post-upgrade step is required to deal with merging
>> >remaining files from /usr/X11R6 into /usr/local.
>> >
>> >3) Once the proposed upgrade method is in place, we will publish a
>> >tarball of the prepared ports tree and request that *all* our ports
>> >developers test the upgrade on their own machines before it is
>> >committed to CVS. There are many things that can go wrong and we ne=
ed
>> >to make sure that the upgrade goes as smoothly as possible for our
>> >less technical users. In particular all ports committers are expect=
ed
>> >to participate in this process of eating our own dogfood :)
>>
>> Any updates on a timeline for this?
>
> Some time this week
>
>>
>> >4) Once a suitable number of success reports (e.g. 50) are received
>> >and all reported issues are resolved, we'll proceed with importing
>> >into CVS.
>> >
>> >5) CVS will stay frozen for a period to be evaluated (probably anoth=
er
>> >couple of weeks) to deal with the inevitable remaining fallout as
>> >users encounter yet more problems with the upgrade.
>>
>> Do you intend to keep the entire ports tree frozen for weeks? Perhaps=
>> I misunderstand?
>
> Yes, that is the plan. This is an "all hands" event, and keeping it
> frozen is the best way to focus developers onto those tasks.
>
> Kris
-- =
me...@cox.net - me...@FreeBSD.org
FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/ - gn...@FreeBSD.org
http://wiki.freebsd.org/multimedia - multi...@FreeBSD.org
Kris Kennaway
> >No, at a minimum I am not comfortable recommending its use until it
> >saves old shared libraries across updates (I sent you email about this
> >a while ago), which is a vital safety and robustness mechanism.
>
> I am one of people that dislike this and it is not required to get build
> function. ;-) I think this option should be disable by default, because
> put stuff in lib/compat/pkg hides the problems. Also:
No, it is required when dealing with shared library bumps (which
happen about once a week). Otherwise all of the installed ports using
the library break if the new library build fails. Talk to Brooks
about how annoying this is with e.g. gettext.
> http://www.freebsd.org/gnome/docs/faq2.html#q2
> ==============================================
> [...]
> Prevent two versions of the same library.
>
> A common source of build failures is the existence of multiple versions of
> the same library. This can happen if you have two different versions of a
> port installed, or can even happen through normal portupgrade use. You can
> back up the libraries in /usr/local/lib/compat/pkg and remove them, and
> then run portupgrade -u -rf pkg-config. This will force a rebuild of all
> GNOME-related apps (and a fair number of other apps) without retaining old
> versions of libraries in /usr/local/lib/compat/pkg.
> ==============================================
I dispute the correctness of this entry. The old libraries in
lib/compat/pkg are not linked to directly by new builds. The only
situation in which something might end up being linked to 2 versions
of the library is if it pulls in a library dependency from an existing
port that is still linked to the old library. In this situation the
build would be broken with or without lib/compat/pkg (in the latter
case, you have an installed port linked to a library that is entirely
missing, so that port will be nonfunctional).
Kris
Jeremy Messenger
=
wrote:
> On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote:
>
>> >No, at a minimum I am not comfortable recommending its use until it
>> >saves old shared libraries across updates (I sent you email about th=
is
>> >a while ago), which is a vital safety and robustness mechanism.
>>
>> I am one of people that dislike this and it is not required to get bu=
ild
>> function. ;-) I think this option should be disable by default, becau=
se
>> put stuff in lib/compat/pkg hides the problems. Also:
>
> No, it is required when dealing with shared library bumps (which
> happen about once a week). Otherwise all of the installed ports using=
> the library break if the new library build fails. Talk to Brooks
> about how annoying this is with e.g. gettext.
portmaster has a feature to backup the old package before the upgrade. I=
=
think it is better than put in lib/compat/pkg. When I used portupgrade a=
nd =
I always have lib/compat/pkg disabled until I switched to portmaster. I =
=
never have that problem when ports tree is flexible enough to downgrade =
=
and wait until someone fix it.
Cheers,
Mezz
>> http://www.freebsd.org/gnome/docs/faq2.html#q2
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> [...]
>> Prevent two versions of the same library.
>>
>> A common source of build failures is the existence of multiple versio=
ns =
>> of
>> the same library. This can happen if you have two different versions =
of =
>> a
>> port installed, or can even happen through normal portupgrade use. Yo=
u =
>> can
>> back up the libraries in /usr/local/lib/compat/pkg and remove them, a=
nd
>> then run portupgrade -u -rf pkg-config. This will force a rebuild of =
all
>> GNOME-related apps (and a fair number of other apps) without retainin=
g =
>> old
>> versions of libraries in /usr/local/lib/compat/pkg.
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> I dispute the correctness of this entry. The old libraries in
> lib/compat/pkg are not linked to directly by new builds. The only
> situation in which something might end up being linked to 2 versions
> of the library is if it pulls in a library dependency from an existing=
> port that is still linked to the old library. In this situation the
> build would be broken with or without lib/compat/pkg (in the latter
> case, you have an installed port linked to a library that is entirely
> missing, so that port will be nonfunctional).
>
> Kris
-- =
me...@cox.net - me...@FreeBSD.org
FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/ - gn...@FreeBSD.org
http://wiki.freebsd.org/multimedia - multi...@FreeBSD.org
Kris Kennaway
> On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway <kr...@obsecurity.org>
>
> >On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote:
> >
> >>>No, at a minimum I am not comfortable recommending its use until it
> >>>a while ago), which is a vital safety and robustness mechanism.
> >>
> >>function. ;-) I think this option should be disable by default, because
> >>put stuff in lib/compat/pkg hides the problems. Also:
> >
> >No, it is required when dealing with shared library bumps (which
> >happen about once a week). Otherwise all of the installed ports using
> >about how annoying this is with e.g. gettext.
>
> portmaster has a feature to backup the old package before the upgrade. I
Well, is this feature enabled by default and does it completely back
out the upgrade if it fails? I may be wrong, but I doubt it is going
to do a complete recursive backout of the upgrade if e.g. one of the
ports depending on the new library fails to build after the library
was updated. If it just restores the old version of this port then it
will be restoring a nonfunctional port, since it links to the version
of the library that was already deleted.
The issue is about providing seat-belts for our users who just want
failed upgrades not to destroy their system. Even if you think that
backing up the package is a better solution than preserving the shared
libraries, it seems to me that portmaster still falls short here
because it doesn't provide a rollback mechanism to restore the system
to a working state when an upgrade fails.
> >I dispute the correctness of this entry. The old libraries in
> >lib/compat/pkg are not linked to directly by new builds. The only
> >situation in which something might end up being linked to 2 versions
> >of the library is if it pulls in a library dependency from an existing
> >port that is still linked to the old library. In this situation the
> >build would be broken with or without lib/compat/pkg (in the latter
> >case, you have an installed port linked to a library that is entirely
> >missing, so that port will be nonfunctional).
> >
> >Kris
I guess your silence means you agree with me here :)
Kris
Brooks Davis
--SLDf9lqlvOQaIe6s
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, May 07, 2007 at 04:44:14PM -0400, Kris Kennaway wrote:
> On Mon, May 07, 2007 at 03:35:48PM -0500, Jeremy Messenger wrote:
> > On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway <kr...@obsecurity.org>=
=20
> > wrote:
> >=20
> > >On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote:
> > >
> > >>>No, at a minimum I am not comfortable recommending its use until it
> > >>>saves old shared libraries across updates (I sent you email about th=
is
> > >>>a while ago), which is a vital safety and robustness mechanism.
> > >>
> > >>I am one of people that dislike this and it is not required to get bu=
ild
> > >>function. ;-) I think this option should be disable by default, becau=
se
> > >>put stuff in lib/compat/pkg hides the problems. Also:
> > >
> > >No, it is required when dealing with shared library bumps (which
> > >happen about once a week). Otherwise all of the installed ports using
> > >the library break if the new library build fails. Talk to Brooks
> > >about how annoying this is with e.g. gettext.
> >=20
> > portmaster has a feature to backup the old package before the upgrade. =
I =20
> > think it is better than put in lib/compat/pkg. When I used portupgrade =
and =20
> > I always have lib/compat/pkg disabled until I switched to portmaster. I=
=20
> > never have that problem when ports tree is flexible enough to downgrade=
=20
> > and wait until someone fix it.
>=20
> Well, is this feature enabled by default and does it completely back
> out the upgrade if it fails? I may be wrong, but I doubt it is going
> to do a complete recursive backout of the upgrade if e.g. one of the
> ports depending on the new library fails to build after the library
> was updated. If it just restores the old version of this port then it
> will be restoring a nonfunctional port, since it links to the version
> of the library that was already deleted.
>=20
> The issue is about providing seat-belts for our users who just want
> failed upgrades not to destroy their system. Even if you think that
> backing up the package is a better solution than preserving the shared
> libraries, it seems to me that portmaster still falls short here
> because it doesn't provide a rollback mechanism to restore the system
> to a working state when an upgrade fails.
For a number of failure modes, the use of pkg_create -b can't do this.
In particularly, pkg_create -b can't ignore missing files (because tar
can't in turn) so you can't make a package of anything with a missing
file. The latest versions of portmaster allow you to ignore this error
by default since it's not as if there's anything else you could do, but
in that situation there's no backing out. Fixing pkg_create would help
here.
The other problem is that if you're going to automatically update all
the dependencies for a port, you need to upgrade all the stuff that
depends on them as well. For example the gettext upgrade got triggered
on my laptop by upgrading something the used gmake. The result was that
virtually nothing outside the base worked any more. Saving the shared
library would have prevented this and allowed a more graceful upgrade
over a few weeks. The fact that a basic desktop setup takes days to
build on fairly fast hardware seems to be an indication that we need a
workaround here. There are other possible solutions, but saving copied
of libraries seems to be the accepted one at the moment.
-- Brooks
--SLDf9lqlvOQaIe6s
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFGP5MKXY6L6fI4GtQRAp/eAKC3+/i8m92j6hENJyb2UcQjzz09NgCdHHEF
zFbrayyrlk/KrH8sdvnMC5U=
=HQK5
-----END PGP SIGNATURE-----
--SLDf9lqlvOQaIe6s--
Jeremy Messenger
wrote:
> On Mon, May 07, 2007 at 03:35:48PM -0500, Jeremy Messenger wrote:
>> On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway <kr...@obsecurity.org>
>> wrote:
>>
>> >On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote:
>> >
>> >>>No, at a minimum I am not comfortable recommending its use until it
>> >>>saves old shared libraries across updates (I sent you email about
>> this
>> >>>a while ago), which is a vital safety and robustness mechanism.
>> >>
>> >>I am one of people that dislike this and it is not required to get
>> build
>> >>function. ;-) I think this option should be disable by default,
>> because
>> >>put stuff in lib/compat/pkg hides the problems. Also:
>> >
>> >No, it is required when dealing with shared library bumps (which
>> >happen about once a week). Otherwise all of the installed ports using
>> >the library break if the new library build fails. Talk to Brooks
>> >about how annoying this is with e.g. gettext.
>>
>> portmaster has a feature to backup the old package before the upgrade. I
>> think it is better than put in lib/compat/pkg. When I used portupgrade
>> and
>> I always have lib/compat/pkg disabled until I switched to portmaster. I
>> never have that problem when ports tree is flexible enough to downgrade
>> and wait until someone fix it.
>
> Well, is this feature enabled by default and does it completely back
> out the upgrade if it fails?
Default.. I am not sure, but I just know that there has option and I have
disable backup in my configure. As for the second question, no, I don't
think it doesn't. The users have to do it by manual to reinstall it.
Correct me if I am wrong. [read other replied from Brooks] Brooks said
that pkg_create has problems that need to be solve. I guess, it has shoot
this down.
> I may be wrong, but I doubt it is going
> to do a complete recursive backout of the upgrade if e.g. one of the
You are right, it doesn't. I don't think it will be easy to add this
feature.
> ports depending on the new library fails to build after the library
> was updated. If it just restores the old version of this port then it
> will be restoring a nonfunctional port, since it links to the version
> of the library that was already deleted.
I think it is rare and will get fix quickly (most of time). It shows real
problem rather than hide it by using old library. This is what I like it.
It helps our package to be more stable in both build and runtime.
> The issue is about providing seat-belts for our users who just want
> failed upgrades not to destroy their system. Even if you think that
> backing up the package is a better solution than preserving the shared
> libraries,
Yes, I think backing up is a better solution. For example, when library
has been bumped but also the plugins, format of configure file or whatever
have been complete revamp. The lib/compat/pkg won't help and the backup
will.
As Brooks said, 'There are other possible solutions, but saving copied of
libraries seems to be the accepted one at the moment.' The 'accepted' is
opposite for me. It's why I am suggesting to disable it by default if
someone is going to add it in portmaster for any users that don't want or
have time to help. ;-)
> it seems to me that portmaster still falls short here
> because it doesn't provide a rollback mechanism to restore the system
> to a working state when an upgrade fails.
>
>> >I dispute the correctness of this entry. The old libraries in
>> >lib/compat/pkg are not linked to directly by new builds. The only
>> >situation in which something might end up being linked to 2 versions
>> >of the library is if it pulls in a library dependency from an existing
>> >port that is still linked to the old library. In this situation the
>> >build would be broken with or without lib/compat/pkg (in the latter
>> >case, you have an installed port linked to a library that is entirely
>> >missing, so that port will be nonfunctional).
>> >
>> >Kris
>
> I guess your silence means you agree with me here :)
Yeah, I guess and unsure at the same time since I didn't write this entry.
:-)
Cheers,
Mezz
> Kris
--
me...@cox.net - me...@FreeBSD.org
FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/ - gn...@FreeBSD.org
http://wiki.freebsd.org/multimedia - multi...@FreeBSD.org
Thierry Thomas
--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Le Lun 7 mai 07 =E0 22:58:50 +0200, Brooks Davis <bro...@freebsd.org>
=E9crivait=A0:
> The other problem is that if you're going to automatically update all
> the dependencies for a port, you need to upgrade all the stuff that
> depends on them as well. For example the gettext upgrade got triggered
> on my laptop by upgrading something the used gmake. The result was that
> virtually nothing outside the base worked any more. Saving the shared
> library would have prevented this and allowed a more graceful upgrade
> over a few weeks. The fact that a basic desktop setup takes days to
> build on fairly fast hardware seems to be an indication that we need a
> workaround here. There are other possible solutions, but saving copied
> of libraries seems to be the accepted one at the moment.
For this kind of upgrades, it's possible to add
libgettextpo.so.1 libgettextpo.so.3
libintl.so.6 libintl.so.8
in your /etc/libmap.conf. Just delete these lines after the storm...
--=20
Th. Thomas.
--AqsLC8rIMeq19msA
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFGP6MDc95pjMcUBaIRApsnAJwNW917j8HWM6yWf6fX4GnbkDDuUwCgjOnm
5OEyPM+stZGZd7Y9v7ZEjOo=
=VKKa
-----END PGP SIGNATURE-----
--AqsLC8rIMeq19msA--
Brooks Davis
--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, May 08, 2007 at 12:06:59AM +0200, Thierry Thomas wrote:
> Le Lun 7 mai 07 ? 22:58:50 +0200, Brooks Davis <bro...@freebsd.org>
> ?crivait?:
>=20
> > The other problem is that if you're going to automatically update all
> > the dependencies for a port, you need to upgrade all the stuff that
> > depends on them as well. For example the gettext upgrade got triggered
> > on my laptop by upgrading something the used gmake. The result was that
> > virtually nothing outside the base worked any more. Saving the shared
> > library would have prevented this and allowed a more graceful upgrade
> > over a few weeks. The fact that a basic desktop setup takes days to
> > build on fairly fast hardware seems to be an indication that we need a
> > workaround here. There are other possible solutions, but saving copied
> > of libraries seems to be the accepted one at the moment.
>=20
> For this kind of upgrades, it's possible to add
>=20
> libgettextpo.so.1 libgettextpo.so.3
> libintl.so.6 libintl.so.8
>=20
> in your /etc/libmap.conf. Just delete these lines after the storm...
I did found out too late that it works in this case, but it's not a
general solution since it only works if the bump was pointless and thus
there aren't prototype mismatches.
-- Brooks
--Qxx1br4bt0+wmkIi
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFGP6VjXY6L6fI4GtQRAqYpAKCJKb+ADFIwO+9X3L8Nqx08NPO4egCeM7hn
r6MU2tH0foIph9z6F6QMSQw=
=GPeO
-----END PGP SIGNATURE-----
--Qxx1br4bt0+wmkIi--
Kris Kennaway
--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, May 08, 2007 at 12:06:59AM +0200, Thierry Thomas wrote:
> Le Lun 7 mai 07 ? 22:58:50 +0200, Brooks Davis <bro...@freebsd.org>
> ?crivait?:
>=20
> > The other problem is that if you're going to automatically update all
> > the dependencies for a port, you need to upgrade all the stuff that
> > depends on them as well. For example the gettext upgrade got triggered
> > on my laptop by upgrading something the used gmake. The result was that
> > virtually nothing outside the base worked any more. Saving the shared
> > library would have prevented this and allowed a more graceful upgrade
> > over a few weeks. The fact that a basic desktop setup takes days to
> > build on fairly fast hardware seems to be an indication that we need a
> > workaround here. There are other possible solutions, but saving copied
> > of libraries seems to be the accepted one at the moment.
>=20
> For this kind of upgrades, it's possible to add
>=20
> libgettextpo.so.1 libgettextpo.so.3
> libintl.so.6 libintl.so.8
>=20
> in your /etc/libmap.conf. Just delete these lines after the storm...
It is possible, but this is not something that non-technical users
will think of (nor should they have to).
The question is whether portmaster is to be considered as a tool for
advanced users only (those who are capable of cleaning up and
repairing damage themselves when an upgrade fails), or if it is
intended as a tool for ordinary users who don't want to (or are not
capable of) doing this kind of manual repair work.
If the goal is the former, then that's OK, but if it is the latter,
then an honest evaluation leads one to conclude that portmaster is
still in the process of maturing towards achieving this goal.
Kris
--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFGP6Z6Wry0BWjoQKURAmidAKDd/cYkNp0uD0FJEHbuDTNbLfXCYwCePq0/
iXrgjyt1h4lX11eZPqXbDEQ=
=2NHE
-----END PGP SIGNATURE-----
--dDRMvlgZJXvWKvBx--
Kris Kennaway
Yes, me either. But you've got to either do one thing or the other.
> >ports depending on the new library fails to build after the library
> >was updated. If it just restores the old version of this port then it
> >will be restoring a nonfunctional port, since it links to the version
> >of the library that was already deleted.
>
> I think it is rare and will get fix quickly (most of time). It shows real
> problem rather than hide it by using old library. This is what I like it.
> It helps our package to be more stable in both build and runtime.
This is the attitude of a ports developer. The attitude of a user is
"what the heck? I just wanted to update my ports and now my desktop
is completely unusable and I have to wait an unspecified time for
someone else to tell me how to fix it."
> >The issue is about providing seat-belts for our users who just want
> >failed upgrades not to destroy their system. Even if you think that
> >backing up the package is a better solution than preserving the shared
> >libraries,
>
> Yes, I think backing up is a better solution. For example, when library
> has been bumped but also the plugins, format of configure file or whatever
> have been complete revamp. The lib/compat/pkg won't help and the backup
> will.
FYI, portupgrade does both, and therefore catches both failure modes.
> As Brooks said, 'There are other possible solutions, but saving copied of
> libraries seems to be the accepted one at the moment.' The 'accepted' is
> opposite for me. It's why I am suggesting to disable it by default if
> someone is going to add it in portmaster for any users that don't want or
> have time to help. ;-)
I don't control what Doug chooses to do with his software, but I can
evaluate the results of those choices and how they impact the utility
of his software for non-technical users of FreeBSD.
> >it seems to me that portmaster still falls short here
> >because it doesn't provide a rollback mechanism to restore the system
> >to a working state when an upgrade fails.
> >
> >>>I dispute the correctness of this entry. The old libraries in
> >>>lib/compat/pkg are not linked to directly by new builds. The only
> >>>situation in which something might end up being linked to 2 versions
> >>>of the library is if it pulls in a library dependency from an existing
> >>>port that is still linked to the old library. In this situation the
> >>>build would be broken with or without lib/compat/pkg (in the latter
> >>>case, you have an installed port linked to a library that is entirely
> >>>missing, so that port will be nonfunctional).
> >>>
> >>>Kris
> >
> >I guess your silence means you agree with me here :)
>
> Yeah, I guess and unsure at the same time since I didn't write this entry.
> :-)
OK.
Kris
Joe Marcus Clarke
--=-jafi7Fo5h8/ISxNouLlt
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Mon, 2007-05-07 at 18:26 -0400, Kris Kennaway wrote:
> > >>>I dispute the correctness of this entry. The old libraries in
> > >>>lib/compat/pkg are not linked to directly by new builds. The only
> > >>>situation in which something might end up being linked to 2 versions
> > >>>of the library is if it pulls in a library dependency from an existi=
ng
> > >>>port that is still linked to the old library. In this situation the
> > >>>build would be broken with or without lib/compat/pkg (in the latter
> > >>>case, you have an installed port linked to a library that is entirel=
y
> > >>>missing, so that port will be nonfunctional).
> > >>>
> > >>>Kris
> > >
> > >I guess your silence means you agree with me here :)
> >=20
> > Yeah, I guess and unsure at the same time since I didn't write this ent=
ry. =20
> > :-)
>=20
> OK.
I didn't write it either, but it holds some truth. Yes, not having the
library at all would cause a build failure, but having multiple versions
of the same library can lead to runtime failures. It's much easier to
troubleshoot a missing .so that it is to hunt down strange runtime
failures (usually).
I'm not arguing for or against portmaster, or the "keeping old shared
objects" functionality. I'm just putting this FAQ entry in context.
Yes, perhaps it could be re-worded for clarity.
Joe
--=20
PGP Key : http://www.marcuscom.com/pgp.asc
--=-jafi7Fo5h8/ISxNouLlt
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQBGP6l6b2iPiv4Uz4cRAh3AAJ41bP4uJqUXBmc3LMYIDX+DZKV90wCgoGAk
AFCqzQ/LUhgkZS2y9vBPGXI=
=zE5q
-----END PGP SIGNATURE-----
--=-jafi7Fo5h8/ISxNouLlt--
Kris Kennaway
--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, May 07, 2007 at 06:34:36PM -0400, Joe Marcus Clarke wrote:
> On Mon, 2007-05-07 at 18:26 -0400, Kris Kennaway wrote:
> > > >>>I dispute the correctness of this entry. The old libraries in
> > > >>>lib/compat/pkg are not linked to directly by new builds. The only
> > > >>>situation in which something might end up being linked to 2 versio=
ns
> > > >>>of the library is if it pulls in a library dependency from an exis=
ting
> > > >>>port that is still linked to the old library. In this situation t=
he
> > > >>>build would be broken with or without lib/compat/pkg (in the latter
> > > >>>case, you have an installed port linked to a library that is entir=
ely
> > > >>>missing, so that port will be nonfunctional).
> > > >>>
> > > >>>Kris
> > > >
> > > >I guess your silence means you agree with me here :)
> > >=20
> > > Yeah, I guess and unsure at the same time since I didn't write this e=
ntry. =20
> > > :-)
> >=20
> > OK.
>=20
> I didn't write it either, but it holds some truth. Yes, not having the
> library at all would cause a build failure, but having multiple versions
> of the same library can lead to runtime failures. It's much easier to
> troubleshoot a missing .so that it is to hunt down strange runtime
> failures (usually).
>=20
> I'm not arguing for or against portmaster, or the "keeping old shared
> objects" functionality. I'm just putting this FAQ entry in context.
> Yes, perhaps it could be re-worded for clarity.
It is true that this situation causes weird runtime errors when it
arises, but the underlying cause is not because of portupgrade's
saving of the old libraries (it's whatever lead to the situation of an
old port not being rebuilt when the shared library version changed).
i.e. probably because a developer forgot to bump the portrevision.
BTW, for users of portupgrade, the libchk port makes tracking down
this kind of problem ("what installed port is linked to the old
library and needs to be rebuilt"?) easy.
Kris
--zhXaljGHf11kAtnf
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFGP6rbWry0BWjoQKURAnhZAKCcftKV2HVvvWl7Sf6b6ASEiwYBZACdHeIB
E3JsDtAgPrkq2cS6KGqHhn0=
=hKBB
-----END PGP SIGNATURE-----
--zhXaljGHf11kAtnf--
Brian Gruber
feature at this time,
>partly because there has been no user demand for it,
and mostly
>because I don't like the idea. I recognize however
that reasonable
>minds may differ on that topic.
if you don't like the idea, that's fine, but since you
say there's been no user demand, i just thought i
should note that I tried portmaster a few months ago.
while there were things i like, i ultimately switched
back to portupgrade specifically because it lacked old
library preservation.
/brian
____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
Garrett Cooper
>> Ok, no worries then. I have no plans to add that
> feature at this time,
>> partly because there has been no user demand for it,
> and mostly
>> because I don't like the idea. I recognize however
> that reasonable
>> minds may differ on that topic.
>
> if you don't like the idea, that's fine, but since you
> say there's been no user demand, i just thought i
> should note that I tried portmaster a few months ago.
> while there were things i like, i ultimately switched
> back to portupgrade specifically because it lacked old
> library preservation.
>
> /brian
Just a thought, but have people considered pushing nVidia and (gasp),
maybe ATI for driver support in 7.2? I would think that AMD would at
least consider FreeBSD if we moved to 7.2 because it seems like they
want to get on the bandwagon with more recent versions of Linux nowadays
with their OpenGL driver support.
Cheers,
-Garrett
Ken Yamada
port tree looks very quiet in these few days and I cannot see any xorg7.2 in my cvsup'd port tree...
Rene Ladan
> Would you please inform the progress (or, schedule), so far?
> port tree looks very quiet in these few days and I cannot see any xorg7.2 in my cvsup'd port tree...
>
look at http://git.xbsd.org/?p=freebsd/ports.git;a=summary to see what
goes on.
Rene
--
GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6
(subkeys.pgp.net)
"It won't fit on the line."
-- me, 2001
Ken Yamada
> Currently most development happens in the git repository. You can
> look at http://git.xbsd.org/?p=freebsd/ports.git;a=summary to see what
> goes on.
No, "http://wiki.freebsd.org/ModularXorg" says;
--Quote--
Disclaimer
If you read about the git repository, forget about it and hold your breath a couple days again. Everything should be merged back to the FreeBSD within a few days.
--Unqote--
git may be maintained, but the page already does not show any of git pages and information, anymore. That is the reason why I am asking...
Florent Thoumie
--------------enigE1F256BF96E2D003C90C7B8D
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Ken Yamada wrote:
> From: "Rene Ladan" <r.c....@gmail.com>
>> Currently most development happens in the git repository. You can
>> look at http://git.xbsd.org/?p=3Dfreebsd/ports.git;a=3Dsummary to see =
what
>> goes on.
>=20
> No, "http://wiki.freebsd.org/ModularXorg" says;
>=20
> --Quote--
> Disclaimer
>=20
> If you read about the git repository, forget about it and hold your bre=
ath a couple days again. Everything should be merged back to the FreeBSD =
within a few days.
> --Unqote--
>=20
> git may be maintained, but the page already does not show any of git pa=
ges and information, anymore. That is the reason why I am asking...
We're committing a last round of fixes and will submit a tarball for
testing hopefully tonight or tomorrow.
As soon as we'll get enough success reports, we'll go all-in.
--=20
Florent Thoumie
f...@FreeBSD.org
FreeBSD Committer
--------------enigE1F256BF96E2D003C90C7B8D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGQE75MxEkbVFH3PQRCgZnAJ0Z9jW2siGX9VIGnj6WwpLGjvkBwQCfZTCg
qsa8zBky0PTAg8PFByvmeT8=
=ch8p
-----END PGP SIGNATURE-----
--------------enigE1F256BF96E2D003C90C7B8D--
Ken Yamada
I understand that we need to be patient another two days...