Re: Simple policy question...
[EMAIL PROTECTED] (Christian Hudon) wrote on 14.06.97 in <[EMAIL PROTECTED]>: > On Jun 13, Sam Ockman wrote > > Okay, so say some random person who has installed Debian wants XEmacs > > 19.15 because he needs some feature. This seems like a reasonable > > request... He could get it from the Hamm distribution, except that would > > mean he'd need libc6...and he doesn't want to do that, because he's heard > > that it will affect the stability of his system. > > The only problem with a mixed libc5/libc6 environment is utmp/wtmp > corruption. (They use different formats.) It certainly doesn't make the It looks as if they also have incompatible locale support, which makes this rather ugly for anyone using locale support. For example, after installing libc6 and friends, _every_ time perl starts, it gives about a dozen lines of error messages about this. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Simple policy question...
On Jun 13, Sam Ockman wrote > Okay, so say some random person who has installed Debian wants XEmacs 19.15 > because he needs some feature. This seems like a reasonable request... He > could get it from the Hamm distribution, except that would mean he'd need > libc6...and he doesn't want to do that, because he's heard that it will > affect the stability of his system. The only problem with a mixed libc5/libc6 environment is utmp/wtmp corruption. (They use different formats.) It certainly doesn't make the system less stable. And it looks like even that one problem will be fixed soon: libc (5.4.33-2) unstable; urgency=low * new release for hamm. As there will be major differences between the bo patch releases and the hamm releases for libc6 compatibility I added some new dependencies. * modified the libc5 internal function reading and writing UTMP entries to use the libc6 format. This will make all programs using the libc functions compatible with the new utmp format as provided by libc6. Please read utmp-wrapper.README in /usr/doc/libc5. -- Helmut Geyer <[EMAIL PROTECTED]> Sat, 7 Jun 1997 20:05:4$ Christian pgpDKmqdEe3f1.pgp Description: PGP signature
Re: Simple policy question...
In article <[EMAIL PROTECTED]>, Alex Yukhimets <[EMAIL PROTECTED]> writes: > The most solid ground not to switch to libc6 is not instability from the > user's point of view (may be libc6 is not that bad), but from the point of > view of developer who's using different kind of commercial developmental > suits. No, that's a good reason not to install libc6 development stuff. It's not a good reason to not install the libc6 runtime and programs that use it, which is what we were talking about. > Unfortunately, as far as I can see, there is no clean way to > have both developmental trees (libc5 and libc6) on the same machine. There cannot be a really good way, but I think they altdev packages are about as good as possible.
Re: Simple policy question...
> Okay, so say some random person who has installed Debian wants XEmacs 19.15 > because he needs some feature. This seems like a reasonable request... He > could get it from the Hamm distribution, except that would mean he'd need > libc6...and he doesn't want to do that, because he's heard that it will > affect the stability of his system. Then that person needs to be corrected. I don't know if libc6 will affect the stability of his system, but I do know that xemacs19 (the xemacs package in hamm currently) doesn't rely on libc6, but rather is still libc5. I also know that installing libc6 will only affect programs that use libc6, not ones that use libc5. I currently have libc4, libc5, and libc6 installed on my system. I run programs that are compiled for all three libraries. So far, no problems that can be traced to libc6. What I would do, if I were he, is go into dselect, put everything on hold, point dselect at hamm, flag xemacs19 for install, then look at the dependancy conflicts dselect complains about. If he wants xemacs19, then he can mark for install or upgrade any packages from hamm that xemacs19 requires. I don't know if there are any, since xemacs19 is compiled against libc5, xlib6 (3.2), ncurses3.0, xpm4.7, zlib1, libjpeg6a, libdb1, libgdbm1, libpng1, all of which are, as far as I know, available in 1.2. > > What then can he do besides compile it himself? If the answer is only > compile it himself...is there a way we can add a special update directory > for 1.3, that will have later versions of programs, and people can > optionally tell dselect to look there? I don't know what you mean here... > > Or am I missing a big part of the picture? > > Thanks, > Sam > > Message from joost witteveen ([EMAIL PROTECTED]) on 6-13-97: > > > Okay, I know that before 1.3 was released, for a long time period the only > > > changes that were being accepted were updates that fixed bugs. Updates > > > that > > > only provided new features were not allowed. > > > > > > Now that 1.3 has "shipped", are updates allowed to replace old packages, > > > or > > > are replacment packages still only allowed that fix specific bugs? (In > > > particular I'm wondering whether we will see Xemacs 19-15 and XFree 3.3 in > > > 1.3.) > > > > Situation of 1.3 is still more-or-less unchaged: only really serious > > bugfixes can go in 1.3.1, after (we have been promised) two weeks > > of testing. > > > > XFree 3.3 has important security fixes, and there seems to be no other > > way to close the security holes currently in debian 1.3.0 than to include > > Xfree 3.3, so there is a chance that will be included. I'm much less > > sure about XEmacs 19.15 though, although I believe it also does fix > > stuff. > > > > -- > VA Research Linux Workstations| The VArServer 4000 File Server > | Four 200Mhz Intel Pentium Pro > CPUs > http://www.varesearch.com | 512MB 60ns EDO ECC/100 GB Raid-5 > Sam Ockman - (415)934-3666, ext. 133 | Linux - $44,339 > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacaphony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Simple policy question...
Okay, I know that before 1.3 was released, for a long time period the only changes that were being accepted were updates that fixed bugs. Updates that only provided new features were not allowed. Now that 1.3 has "shipped", are updates allowed to replace old packages, or are replacment packages still only allowed that fix specific bugs? (In particular I'm wondering whether we will see Xemacs 19-15 and XFree 3.3 in 1.3.) Thanks, Sam -- VA Research Linux Workstations| The VArServer 4000 File Server | Four 200Mhz Intel Pentium Pro CPUs http://www.varesearch.com | 512MB 60ns EDO ECC/100 GB Raid-5 Sam Ockman - (415)934-3666, ext. 133 | Linux - $44,339 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Simple policy question...
> Okay, I know that before 1.3 was released, for a long time period the only > changes that were being accepted were updates that fixed bugs. Updates that > only provided new features were not allowed. > > Now that 1.3 has "shipped", are updates allowed to replace old packages, or > are replacment packages still only allowed that fix specific bugs? (In > particular I'm wondering whether we will see Xemacs 19-15 and XFree 3.3 in > 1.3.) Situation of 1.3 is still more-or-less unchaged: only really serious bugfixes can go in 1.3.1, after (we have been promised) two weeks of testing. XFree 3.3 has important security fixes, and there seems to be no other way to close the security holes currently in debian 1.3.0 than to include Xfree 3.3, so there is a chance that will be included. I'm much less sure about XEmacs 19.15 though, although I believe it also does fix stuff. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Simple policy question...
Okay, so say some random person who has installed Debian wants XEmacs 19.15 because he needs some feature. This seems like a reasonable request... He could get it from the Hamm distribution, except that would mean he'd need libc6...and he doesn't want to do that, because he's heard that it will affect the stability of his system. What then can he do besides compile it himself? If the answer is only compile it himself...is there a way we can add a special update directory for 1.3, that will have later versions of programs, and people can optionally tell dselect to look there? Or am I missing a big part of the picture? Thanks, Sam Message from joost witteveen ([EMAIL PROTECTED]) on 6-13-97: > > Okay, I know that before 1.3 was released, for a long time period the only > > changes that were being accepted were updates that fixed bugs. Updates that > > only provided new features were not allowed. > > > > Now that 1.3 has "shipped", are updates allowed to replace old packages, or > > are replacment packages still only allowed that fix specific bugs? (In > > particular I'm wondering whether we will see Xemacs 19-15 and XFree 3.3 in > > 1.3.) > > Situation of 1.3 is still more-or-less unchaged: only really serious > bugfixes can go in 1.3.1, after (we have been promised) two weeks > of testing. > > XFree 3.3 has important security fixes, and there seems to be no other > way to close the security holes currently in debian 1.3.0 than to include > Xfree 3.3, so there is a chance that will be included. I'm much less > sure about XEmacs 19.15 though, although I believe it also does fix > stuff. -- VA Research Linux Workstations| The VArServer 4000 File Server | Four 200Mhz Intel Pentium Pro CPUs http://www.varesearch.com | 512MB 60ns EDO ECC/100 GB Raid-5 Sam Ockman - (415)934-3666, ext. 133 | Linux - $44,339 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Simple policy question...
> Okay, so say some random person who has installed Debian wants XEmacs 19.15
> because he needs some feature. This seems like a reasonable request... He
> could get it from the Hamm distribution, except that would mean he'd need
> libc6...and he doesn't want to do that, because he's heard that it will
> affect the stability of his system.
>
> What then can he do besides compile it himself? If the answer is only
> compile it himself...is there a way we can add a special update directory
> for 1.3, that will have later versions of programs, and people can
> optionally tell dselect to look there?
>
> Or am I missing a big part of the picture?
>
> Thanks,
> Sam
That is exactly what I posted on the list a few days ago. Unfotunately
there was the only response (from Brian White -- thanks). I proposed to
have "unsupported" directory with the updates of this kind which would not
officially belong to the Debian 1.3.* .
The most solid ground not to switch to libc6 is not instability from the
user's point of view (may be libc6 is not that bad), but from the point of
view of developer who's using different kind of commercial developmental
suits.
Unfortunately, as far as I can see, there is no clean way to
have both developmental trees (libc5 and libc6) on the same machine.
And what even more unfortunate, Debian's goal does not seem to have
a good "transformation period system", where ALL tricky points of two
libraries coexistence are resolved, but to switch EVERYTHING to libc6
as soon as possible. The only outcome of this would the loss of quite a
few serious developers for Debian's community.
Thank you,
Alex Y.
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
