Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

> I suggest you take a look at > > >http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/ Thank you ! This confused the hell out of me when I first bumped into it on Solaris ! Something to read in the morning -- Brian <[EMAIL PROTECTED]

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Thu, Feb 15, 2001 at 12:44:26PM +, Paul Richards_imap/mail.originative.co.uk/Inbox.sbd/New Mail.sbd/OpenLDAP.sbd/Devel wrote: > I suggest you take a look at > > >http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/ Yes, I know how So

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

David O'Brien wrote: > > On Thu, Feb 15, 2001 at 11:14:38AM +, Paul Richards wrote: > > Commercial vendors will skip version numbers in their public releases > > if their internal development required more than one bump. > > Which ones? Sun Solaris still ships their libc as "libc.so.1", eve

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Thu, Feb 15, 2001 at 11:14:38AM +, Paul Richards wrote: > Commercial vendors will skip version numbers in their public releases > if their internal development required more than one bump. Which ones? Sun Solaris still ships their libc as "libc.so.1", even in Solaris 8. -- -- David ([E

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

David O'Brien wrote: > > We only bumped due to interface changes in the .MAJOR.MINOR days. The > difference is *adding* an interface today does in cause a bump. In the > .MAJOR.MINOR days it would require a bump the MINOR number. In both > days, an incompatible change in an existing interfac

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Wed, Feb 14, 2001 at 12:47:59AM +, Paul Richards wrote: > Instead what we have now is libxyz.so.3 and libxyz.so.3 which are > different from each other. No different than two libxyz.so.3.1 and libxyz.so.3.1 could be (a.out days). (well not entirely true, but in the a.out days, one could ma

Re: -CURRENT is bad for me...

On Mon, Feb 12, 2001 at 07:59:03AM -0500, Daniel Eischen wrote: >Did you miss the HEADS UP posted to -current? You better read these. Somehow, I just didn't notice that there is a HEADS UP. I have bang my head to the wall because of this sillyness I've done :( I have just reformat my box, and

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Wed, Feb 14, 2001 at 00:47 +, Paul Richards wrote: > > To be honest, DLLs are better than our scheme from that > perspective. While you might screw a load of applications by > upgrading a DLL with the same name you can at least look at the > version number in the properties to find out wh

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

David O'Brien wrote: > > On Tue, Feb 13, 2001 at 04:24:00PM +, Paul RichardsF wrote: > > When we dropped minor numbers I had a worry that we'd run into one of > > Windows' greatest problems and we have. Applications that are developed > > and tested to work with a particular library might not

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Tue, Feb 13, 2001 at 04:24:00PM +, Paul RichardsF wrote: > When we dropped minor numbers I had a worry that we'd run into one of > Windows' greatest problems and we have. Applications that are developed > and tested to work with a particular library might not work with a > different version

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Garrett Wollman wrote: > < said: > > > There is no concept of "forward" or "backward" as far as the toolchain and > > runtime support goes. There is only "filename exists" or "file not found". > > This is a human-factors issue, not a code issue. People expect to see > version numbers increasin

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Dag-Erling Smorgrav wrote: > > Warner Losh <[EMAIL PROTECTED]> writes: > > I've had problems in the past going backwards on major versions of > > shared libaries. The major problem is that if I have binaries that > > refer to libc.so.503, then when the major number is reverted back to > > 5, it

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

< said: > There is no concept of "forward" or "backward" as far as the toolchain and > runtime support goes. There is only "filename exists" or "file not found". This is a human-factors issue, not a code issue. People expect to see version numbers increasing. -GAWollman To Unsubscribe: sen

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Garrett Wollman wrote: > < said: > > > If we had taken -current to 500, we could go to 501, 502, etc as > > required to stop killing our developers, and prior to entering 5.0-BETA we > > go back to the next sequentially available major number (be it 5, or 6 > > if RELENG_4 bumps again). > > Sha

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

< said: > If we had taken -current to 500, we could go to 501, 502, etc as > required to stop killing our developers, and prior to entering 5.0-BETA we > go back to the next sequentially available major number (be it 5, or 6 > if RELENG_4 bumps again). Shared library version numbers going backw

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes: >Daniel Eischen <[EMAIL PROTECTED]> writes: >> Attached is a patch that attempts to work around recent stdio >> breakage in -current. I've verified it compiles, but won't be >> able to test it until at least tomorrow. If someone wants t

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Matt Dillon writes: : How about a temporary LD_LIBRARY path to run the tools, pointing into : /usr/obj somewhere? We'd have to copy the current libraries to that location, or at least into /tmp. These are *HOST* binaries after all. And the hacking to do th

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

:In message <[EMAIL PROTECTED]> Matt Dillon writes: ::Would compiling the tools -static help? : :No. The tools that are deployed today are not static, and it is those :that we copy. It will also delay discovery of the incompatibility :until after the installworld is complete. I'm not sure

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Matt Dillon writes: :Would compiling the tools -static help? No. The tools that are deployed today are not static, and it is those that we copy. It will also delay discovery of the incompatibility until after the installworld is complete. I'm not sure that wo

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Would compiling the tools -static help? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Tue, Feb 13, 2001 at 02:29:54AM +0100, Dag-Erling Smorgrav wrote: > We can keep that bias by using temporary three-digit majors in > -CURRENT and backing down to a single-digit major right before the > first -RELEASE. In this specific case, we'd go from 5 to 500 or 501, Please read your -arch

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Mon, Feb 12, 2001 at 05:44:53PM -0800, Peter Wemm wrote: > "David O'Brien" wrote: > > Actually going from libc.so.500 to libc.so.{x<500} is easy. > > Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to > > libc.so.{x<500}, that is the lib version number that will get burned

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Tue, Feb 13, 2001 at 02:42:15AM +0100, Dag-Erling Smorgrav wrote: > Warner Losh <[EMAIL PROTECTED]> writes: > > I've had problems in the past going backwards on major versions of > > shared libaries. The major problem is that if I have binaries that > > refer to libc.so.503, then when the majo

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Dag-Erling Smorgrav wrote: > Warner Losh <[EMAIL PROTECTED]> writes: > > I've had problems in the past going backwards on major versions of > > shared libaries. The major problem is that if I have binaries that > > refer to libc.so.503, then when the major number is reverted back to > > 5, it is

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Mon, Feb 12, 2001 at 05:44:31PM -0800, Peter Wemm wrote: > We could use dates, current time_t, anything. /usr/lib/libc.so.whistler (Sorry, working for MS I couldn't resist :-) -- Jos Backus _/ _/_/_/"Modularity is not a hack." _/ _/ _/

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes: : When we back down to 5, we add magic to the Makefiles to move : libc.so.5?? to /usr/lib/compat - that way they're only used when : needed at runtime, not for linking new programs. No need. I misunderstood how ELF libraries work. The l

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

"David O'Brien" wrote: > Actually going from libc.so.500 to libc.so.{x<500} is easy. > Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to > libc.so.{x<500}, that is the lib version number that will get burned into > objects. After the first `make world', rm /usr/lib/libc.so.

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > When we back down to 5, we add magic to the Makefiles to move > libc.so.5?? to /usr/lib/compat - that way they're only used when > needed at runtime, not for linking new programs. Umm, never mind this gross hack; as Peter pointed out, it's not a p

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Warner Losh <[EMAIL PROTECTED]> writes: > I've had problems in the past going backwards on major versions of > shared libaries. The major problem is that if I have binaries that > refer to libc.so.503, then when the major number is reverted back to > 5, it is a nop because ld will use libc.so.503

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Alfred Perlstein writes: : > Actually going from libc.so.500 to libc.so.{x<500} is easy. : > Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to : > libc.so.{x<500}, that is the lib version number that will get burned into : > objects. After the

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> "David O'Brien" writes: : > What's wrong with shipping with say libc.so.505 in 5.0 and then say : > libc.so.645 in 6.0? : : HACK. I think it is an astheitc issue only. It is not a hack, but how ELF shared libarires work. However, since it is easy to move from 505

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Peter Wemm <[EMAIL PROTECTED]> writes: > at which point any stdio using dynamic binary is hosed, including the > *USELESS* copies in /tmp that installworld stashed away. Is it possible to produce a static executable from a dynamic one, provided the right libs are available? In that case, the init

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

* David O'Brien <[EMAIL PROTECTED]> [010212 17:35] wrote: > On Mon, Feb 12, 2001 at 06:26:06PM -0700, Warner Losh wrote: > > I don't see why we need only an increment of 1. What does this buy us > > other than a minor warm fuzzy. > > It is hackish. > > > OpenBSD bumps libc bunchs of times per

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Mon, Feb 12, 2001 at 06:31:53PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Peter Wemm writes: > : If we had taken -current to 500, we could go to 501, 502, etc as > : required to stop killing our developers, and prior to entering 5.0-BETA we > : go back to the next sequentially

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Alfred Perlstein writes: : Er, why isn't /tmp/install.XXX done with static binaries? Because the binaries are host binaries and we have no control over whether they are static or dynmaic. At best we could do is to copy libraries over as well. But I think the major

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Peter Wemm writes: : Warner Losh wrote: : significance to the naming at all. The versioning is done at link time : by the libfoo.so -> libfoo.so.N symlink. Ah. That's different. If it is that easy, then my objection is withdrawn. I wasted about 3 days trying to

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Peter Wemm <[EMAIL PROTECTED]> writes: > install -c libc.so.5 /usr/lib > install -c libc_pic.a /usr/lib > /usr/libexec/ld-elf.so.1: undefined symbol __sF in COPY relocation > > at which point any stdio using dynamic binary is hosed, including the > *USELESS* copies in /tmp that installworld stash

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Mon, Feb 12, 2001 at 06:26:06PM -0700, Warner Losh wrote: > I don't see why we need only an increment of 1. What does this buy us > other than a minor warm fuzzy. It is hackish. > OpenBSD bumps libc bunchs of times per release cycle (they are up to > libc.so.24 if my sources are current).

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

* Peter Wemm <[EMAIL PROTECTED]> [010212 17:28] wrote: > Dag-Erling Smorgrav wrote: > > Peter Wemm <[EMAIL PROTECTED]> writes: > > > Sorry, I made the mistake of looking at this bikeshed and lost my nerve. > > > The patch I was going to commit was: > > > http://people.freebsd.org/~peter/stdio.diff

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Mon, 12 Feb 2001, Peter Wemm wrote: > Daniel Eischen wrote: > > > Attached is a patch that attempts to work around recent stdio > > breakage in -current. I've verified it compiles, but won't be > > able to test it until at least tomorrow. If someone wants to > > review it and verify it works

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Warner Losh wrote: > In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes: > : Peter Wemm <[EMAIL PROTECTED]> writes: > : > http://people.freebsd.org/~peter/stdio.diff3 > : > : Except that we bump to 500 instead of 6, and back to 5 before > : -RELEASE. > > I don't think this will work. It

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Peter Wemm writes: : If we had taken -current to 500, we could go to 501, 502, etc as : required to stop killing our developers, and prior to entering 5.0-BETA we : go back to the next sequentially available major number (be it 5, or 6 : if RELENG_4 bumps again). I

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Warner Losh <[EMAIL PROTECTED]> writes: > I'd like to see a bias against major bumps remain in place, but I > think that this change requires one. That is, we still don't > generally bump major verions, but are allowed to when the pain is > major. We can keep that bias by using temporary three-d

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Mon, Feb 12, 2001 at 06:21:58PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Peter Wemm writes: > : Personally, I think we place far too much weight on the major number thing. > : I think we should be allowed to bump it when the alternative is 'major pain' > : to developers. > >

Re: -CURRENT is bad for me...

> Mike Smith wrote: > > > On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: > > > > > > > You can do better than this. Put the lock in FILE, and define a new > > > > structure FILE_old, which has the same size/layout as the old FILE > > > > structure. > > > > > > How is this more ac

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Dag-Erling Smorgrav wrote: > Peter Wemm <[EMAIL PROTECTED]> writes: > > Sorry, I made the mistake of looking at this bikeshed and lost my nerve. > > The patch I was going to commit was: > > http://people.freebsd.org/~peter/stdio.diff3 > > .. but this *totally* breaks installworld due to *BAD* brok

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Mon, Feb 12, 2001 at 05:20:51PM -0800, Peter Wemm wrote: > It avoids the current problem: > - RELENG_4 bumped from 3.0 to 4.0 > - this forced a premature 4.0->5.0 bump in -current Actually "NO". I bumped libc.so because Garret said he had changes ready for libc, but was waiting for someone to

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes: : Peter Wemm <[EMAIL PROTECTED]> writes: : > http://people.freebsd.org/~peter/stdio.diff3 : : Except that we bump to 500 instead of 6, and back to 5 before : -RELEASE. I don't think this will work. It is hard to downgrade a major number

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Peter Wemm writes: : Personally, I think we place far too much weight on the major number thing. : I think we should be allowed to bump it when the alternative is 'major pain' : to developers. The more I think about this, the more that I think that you are right. I'

Re: -CURRENT is bad for me...

Mike Smith wrote: > > On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: > > > > > You can do better than this. Put the lock in FILE, and define a new > > > structure FILE_old, which has the same size/layout as the old FILE > > > structure. > > > > How is this more acceptable than bu

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Daniel Eischen wrote: > Attached is a patch that attempts to work around recent stdio > breakage in -current. I've verified it compiles, but won't be > able to test it until at least tomorrow. If someone wants to > review it and verify it works, I'll commit it. > > Thanks, > __BEGIN_DECLS >

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Dag-Erling Smorgrav wrote: > Peter Wemm <[EMAIL PROTECTED]> writes: > > http://people.freebsd.org/~peter/stdio.diff3 > > Except that we bump to 500 instead of 6, and back to 5 before > -RELEASE. > > When we've branched RELENG_5, if we need to bump libc's major in > 6.0-CURRENT, we bump it to 600

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Tue, Feb 13, 2001 at 02:14:03AM +0100, Dag-Erling Smorgrav wrote: > > No, it doesn't, because you bumped the libc major. Set it to 500 like > we discussedm, and commit (or I will, damnit). Uh, NO. It was discussed on IRC, NOT -arch. It needs to go there before doing something like this. -

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Peter Wemm <[EMAIL PROTECTED]> writes: > Sorry, I made the mistake of looking at this bikeshed and lost my nerve. > The patch I was going to commit was: > http://people.freebsd.org/~peter/stdio.diff3 > .. but this *totally* breaks installworld due to *BAD* brokenness in > installworld. No, it doe

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Mon, Feb 12, 2001 at 05:09:19PM -0800, Peter Wemm wrote: > I can deal with /usr/local and /usr/X11R6 recompiles, but when the > installworld dies because the dynamic linked copy of /usr/bin/* in > /tmp/XXX/* gets the /usr/lib/libc.so.5 clobbered and explodes, leaving > a 100% totally screwed up

Re: -CURRENT is bad for me...

> On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: > > > You can do better than this. Put the lock in FILE, and define a new > > structure FILE_old, which has the same size/layout as the old FILE > > structure. > > How is this more acceptable than bumping the major number? Are the

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Warner Losh wrote: > In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes: > : Warner Losh <[EMAIL PROTECTED]> writes: > : > I'd rather see this patch, or something similar, than bump the major > : > version again. We can phase in a better way to obviate the need to do > : > this in the futu

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Peter Wemm <[EMAIL PROTECTED]> writes: > http://people.freebsd.org/~peter/stdio.diff3 Except that we bump to 500 instead of 6, and back to 5 before -RELEASE. When we've branched RELENG_5, if we need to bump libc's major in 6.0-CURRENT, we bump it to 600, then 601 etc. as many times as we want, a

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Dag-Erling Smorgrav wrote: > Warner Losh <[EMAIL PROTECTED]> writes: > > I'd rather see this patch, or something similar, than bump the major > > version again. We can phase in a better way to obviate the need to do > > this in the future. > > Brian Feldman, Peter Wemm, David O'Brien and myself

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Mon, Feb 12, 2001 at 04:33:26PM -0800, Alex Zepeda wrote: > How about this? :^) Because bumping the shared version again needs *DISCUSSING*. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Warner Losh wrote: > In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes: > : Daniel Eischen <[EMAIL PROTECTED]> writes: > : > Attached is a patch that attempts to work around recent stdio > : > breakage in -current. I've verified it compiles, but won't be > : > able to test it until at lea

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Mon, Feb 12, 2001 at 07:28:30PM -0500, Daniel Eischen wrote: > Attached is a patch that attempts to work around recent stdio > breakage in -current. I've verified it compiles, but won't be > able to test it until at least tomorrow. If someone wants to > review it and verify it works, I'll com

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Warner Losh <[EMAIL PROTECTED]> writes: > If there's something better than Daniel's solution that doesn't > require a major bump and is compatible with the old libc.so.5 api, > then I'm all for that. I'd love to test it out as well if there's any > desire for that. Yes, there is. Steal _cookie,

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On 13 Feb 2001, Dag-Erling Smorgrav wrote: > Warner Losh <[EMAIL PROTECTED]> writes: > > I'd rather see this patch, or something similar, than bump the major > > version again. We can phase in a better way to obviate the need to do > > this in the future. > > Brian Feldman, Peter Wemm, David O'B

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Tue, Feb 13, 2001 at 01:48:33AM +0100, Dag-Erling Smorgrav wrote: > Peter will likely commit a patch sometime soon. I am hoping it is posted for discussion to -arch before commit (so we get this right). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in th

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes: : Warner Losh <[EMAIL PROTECTED]> writes: : > I'd rather see this patch, or something similar, than bump the major : > version again. We can phase in a better way to obviate the need to do : > this in the future. : : Brian Feldman, Peter

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Warner Losh <[EMAIL PROTECTED]> writes: > I'd rather see this patch, or something similar, than bump the major > version again. We can phase in a better way to obviate the need to do > this in the future. Brian Feldman, Peter Wemm, David O'Brien and myself have been discussing possible solutions

Re: -CURRENT is bad for me...

On Mon, Feb 12, 2001 at 01:42:16PM -0800, Alex Zepeda wrote: > Yup, I agree here. IMO so many things depend on the stdio bits, that a > major number increase would have been desireable. So far, bzip2, > pine/pico, GNU make, the GNU i18n stuff, fetchmail all needed to be > rebuilt. Bumping the m

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes: : Daniel Eischen <[EMAIL PROTECTED]> writes: : > Attached is a patch that attempts to work around recent stdio : > breakage in -current. I've verified it compiles, but won't be : > able to test it until at least tomorrow. If someone want

Re: -CURRENT is bad for me...

In message <[EMAIL PROTECTED]> "David O'Brien" writes: : On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote: : > Changes of this magnitude require a bump of the major number, even : > though we've already done that in -current. It breaks nearly : > everything, including the upgrade path.

Re: -CURRENT is bad for me...

On Mon, Feb 12, 2001 at 04:20:04PM -0800, Alex Zepeda wrote: > How is this more acceptable than bumping the major number? Are they > really so precious that they can only be incremented once for a release > cycle? Yes. I don't want to be in a position where we wonder what happened to libc.so.

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

Daniel Eischen <[EMAIL PROTECTED]> writes: > Attached is a patch that attempts to work around recent stdio > breakage in -current. I've verified it compiles, but won't be > able to test it until at least tomorrow. If someone wants to > review it and verify it works, I'll commit it. Please. Let'

Re: -CURRENT is bad for me...

On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote: > Changes of this magnitude require a bump of the major number, even > though we've already done that in -current. It breaks nearly > everything, including the upgrade path. How does it break the upgrade path from 4.x to 5.0?? 5.0 has

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

In message <[EMAIL PROTECTED]> Daniel Eischen writes: : Attached is a patch that attempts to work around recent stdio : breakage in -current. I've verified it compiles, but won't be : able to test it until at least tomorrow. If someone wants to : review it and verify it works, I'll commit it. T

Re: -CURRENT is bad for me...

On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: > You can do better than this. Put the lock in FILE, and define a new > structure FILE_old, which has the same size/layout as the old FILE > structure. How is this more acceptable than bumping the major number? Are they really so pr

Patch for FILE problems (was Re: -CURRENT is bad for me...)

Attached is a patch that attempts to work around recent stdio breakage in -current. I've verified it compiles, but won't be able to test it until at least tomorrow. If someone wants to review it and verify it works, I'll commit it. Thanks, -- Dan Eischen Index: include/stdio.h ==

Re: -CURRENT is bad for me...

Warner Losh <[EMAIL PROTECTED]> writes: > Alternatively, the upgrade path must be fixed. I don't see any way to do that. Everything on your system that isn't statically linked will need to be recompiled unless the libc major number is bumped. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To

Re: -CURRENT is bad for me...

On Mon, 12 Feb 2001, Mike Smith wrote: > > > Then wouldn't the "partially applied patch" rule apply? eg, back it > > > out until the issues can be resolved. Breaking the upgrade path isn't > > > acceptible. > > > > If you bump the library versions, doesn't that fix the upgrade > > path? > > No

Re: -CURRENT is bad for me...

> > Then wouldn't the "partially applied patch" rule apply? eg, back it > > out until the issues can be resolved. Breaking the upgrade path isn't > > acceptible. > > If you bump the library versions, doesn't that fix the upgrade > path? No, because the library version bump has already happened

Re: -CURRENT is bad for me...

On Mon, 12 Feb 2001, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Daniel >Eischen writes: > : On Mon, 12 Feb 2001, Warner Losh wrote: > : > To be blunt, the FILE * changes go too far, even for -current. > : > : Other than having to installworld twice, I've had zero problems. > : But I don

Re: -CURRENT is bad for me...

On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote: > Changes of this magnitude require a bump of the major number, even > though we've already done that in -current. It breaks nearly > everything, including the upgrade path. Alternatively, the locking > changes need to be backed out.

Re: -CURRENT is bad for me...

> > Then wouldn't the "partially applied patch" rule apply? eg, back it > out until the issues can be resolved. Breaking the upgrade path isn't > acceptible. I have to "me too" this; the change simply isn't OK. There are a variety of ways that we can work around the issue and maintain binary

Re: -CURRENT is bad for me...

In message <[EMAIL PROTECTED]> Daniel Eischen writes: : On Mon, 12 Feb 2001, Warner Losh wrote: : > To be blunt, the FILE * changes go too far, even for -current. : : Other than having to installworld twice, I've had zero problems. : But I don't recompile my applications often, and am probably :

Re: -CURRENT is bad for me...

On Mon, 12 Feb 2001, Warner Losh wrote: > To be blunt, the FILE * changes go too far, even for -current. Other than having to installworld twice, I've had zero problems. But I don't recompile my applications often, and am probably still running things that depend on libc.so.4. > Changes of this

Re: -CURRENT is bad for me...

To be blunt, the FILE * changes go too far, even for -current. Changes of this magnitude require a bump of the major number, even though we've already done that in -current. It breaks nearly everything, including the upgrade path. Alternatively, the locking changes need to be backed out. Alter

Re: -CURRENT is bad for me...

On Mon, 12 Feb 2001, John Indra wrote: > Just finished buildworld on recent -CURRENT. installworld target died with > this: > > ===> gnu/usr.bin/perl/suidperl > install -c -s -o root -g wheel -m 511 suidperl /usr/bin > /usr/bin/sperl5 -> /usr/bin/suidperl > /usr/bin/sperl5.6.0 -> /usr/bin/suidp

-CURRENT is bad for me...

Just finished buildworld on recent -CURRENT. installworld target died with this: ===> gnu/usr.bin/perl/suidperl install -c -s -o root -g wheel -m 511 suidperl /usr/bin /usr/bin/sperl5 -> /usr/bin/suidperl /usr/bin/sperl5.6.0 -> /usr/bin/suidperl ===> gnu/usr.bin/perl/library sed: stdout: Bad fi