Re: support for older distributions
Craig == Craig Sanders [EMAIL PROTECTED] writes: Craig debian provides mechanisms for easy upgrade between release Craig versions, and we always have provided that - why complicate Craig matters with branched sub-releases of old versions? You say stable is old. That is exactly Russell's point. Some people want a mostly stable system, but need some up-to-date packages from woody. I wouldn't suggest going any further back then stable though. Craig for example, ask yourself: why is libc6-2.2.2-potato1 (or Craig whatever the potato version would be) any better or Craig safer than just installing libc6-2.2.2 from woody or sid? Craig i can't see how it could be, and all you've achieved is Craig having two divergent versions of 2.2.2 to support. I think you missed Russell's point. That was: compile unstable packages against stable's libc6. So libc6 would not be included in this list. Craig debian is a live distribution, easily upgraded in place Craig at any time over the internet - why limit yourself to Craig looking at debian in a way which is more suited to Craig commercial CD-ROM only closed source systems? Because some people don't want to upgrade libc6 on a stable system (ie. they want a mostly stable system), but require new features of particular packages in unstable, and are willing to risk the chance that these new packages may be broken. Craig IMO, forcing debian into that model is missing a large part Craig of the point of debian. Craig potato's been released. woody's getting closer to Craig freeze. lets move on. woody's release is still months away (dare I say almost a year?). Sure, another approach is to compile your own version of the unstable package, but Russell takes then one step further to have a central repository for unstable package for stable. Instead of the current situation of having many different apt repositories, each with different selections of packages compiled for stable, you would have one big repository that could be used by everyone. -- Brian May [EMAIL PROTECTED]
Re: support for older distributions
On Wednesday 09 May 2001 02:32, Craig Sanders wrote: Currently there are two usable repositories of Potato packages. There's a repository of kernel-related packages to run 2.4.x kernels on Potato, and there's a repository of LDAP related packages and other things that Wichert is maintaining. Both of these are good work, but even combined they don't provide what I consider to be adequate support for Potato. I would like a version of Potato that is not entirely frozen. It should have updates not only for security reasons but also for addition of new programs, and for adding new programs which add significant functionality and don't break things (such as Wichert's LDAP packages). why? your suggestion would add a huge load of administrative and maintainence overhead in order to support a convenient fiction - providing little or no real benefit. worse than that, it subverts the only real point in having versioned releases - the ability to know what is included in any released version. No. You can get the potato distribution which has the stable versions of software and then selectively apply new versions where you need them. you also risk creating greater problems back-porting packages from testing or unstable - they would be divergent packages which don't get anywhere near the same amount of testing and usage as packages in the mainline development cycle. for example, ask yourself: why is libc6-2.2.2-potato1 (or whatever the potato version would be) any better or safer than just installing libc6-2.2.2 from woody or sid? i can't see how it could be, and all you've achieved is having two divergent versions of 2.2.2 to support. I didn't anticipate that anyone would want to back-port something as core as libc6. The idea is that you can run the latest postfix (for example) on the old libc6. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: support for older distributions
On Wed, May 09, 2001 at 04:49:04PM +1000, Brian May wrote: You say stable is old. That is exactly Russell's point. Some people want a mostly stable system, but need some up-to-date packages from woody. that's a choice people have to make. you can have an old 'stable' release, or you can have an up-to-date 'unstable' release. there really is no in-between, no matter how hard you might try to convince yourself otherwise. if you upgrade one package, you may have to upgrade another...and another...and if you're going to do that, you're better off upgrading to the version(s) in unstable because they're more likely to be tested and debugged by other people than a package recompiled for an old debian release. I wouldn't suggest going any further back then stable though. Craig for example, ask yourself: why is libc6-2.2.2-potato1 (or Craig whatever the potato version would be) any better or Craig safer than just installing libc6-2.2.2 from woody or sid? Craig i can't see how it could be, and all you've achieved is Craig having two divergent versions of 2.2.2 to support. I think you missed Russell's point. That was: compile unstable packages against stable's libc6. So libc6 would not be included in this list. libc6 was only an example. if not libc6, then libgtk or libfoo or libbar - or any application or tool. why is application bar any *more* reliable or trustworthy just because it is compiled against an old version of libc6 in potato? it's not. all you're doing is deluding yourself that your system is more stable than it would be if it was running unstable. the truth is that it is likely to be *less* stable because that particular combination of compiler/libraries/application version is less tested than what is in unstable. the sole advantage to this is so that you can lie to your boss and say we're running the stable release and be telling only a half-truth (or half-lie...doesn't matter, it's still bullshit) now it's your system, you can do whatever you want with it. that's not the point i'm making. i just don't like self-deception being touted as reality. Craig debian is a live distribution, easily upgraded in place Craig at any time over the internet - why limit yourself to Craig looking at debian in a way which is more suited to Craig commercial CD-ROM only closed source systems? Because some people don't want to upgrade libc6 on a stable system (ie. they want a mostly stable system), but require new features of particular packages in unstable, and are willing to risk the chance that these new packages may be broken. isn't this what 'testing' was supposed to be for? so that people could run almost-bleeding-edge systems where packages have had the really serious bugs discovered and fixed by foolhardy people like me who run unstable? Craig IMO, forcing debian into that model is missing a large part Craig of the point of debian. Craig potato's been released. woody's getting closer to Craig freeze. lets move on. woody's release is still months away (dare I say almost a year?). it might not take so long if people didn't get distracted by obsessively backporting rather than moving on to the next release. Sure, another approach is to compile your own version of the unstable package, but Russell takes then one step further to have a central repository for unstable package for stable. Instead of the current situation of having many different apt repositories, each with different selections of packages compiled for stable, you would have one big repository that could be used by everyone. a fine idea (really, i'm not being sarcastic). but ALL it is doing is making yet another unstable. think about it: that's all it is - just another unstable tree, but with different versions of stuff. why bother? craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: support for older distributions
Craig == Craig Sanders [EMAIL PROTECTED] writes: Craig why is application bar any *more* reliable or trustworthy Craig just because it is compiled against an old version of libc6 Craig in potato? It is not so much the new application I was thinking of, but all the old stable applications that already exist on the system. So recompiling foo for stable might produce a broken version of foo. fine. Downgrade or remove the package again. Problem solved. Nothing lost in the process, except time taken to down load, recompile and test the package. But installing a new version of libc6 on a stable system has the potential for breaking the whole system. -- Brian May [EMAIL PROTECTED]
Re: support for older distributions
On Wed, May 09, 2001 at 06:36:30PM +1000, Brian May wrote: Craig == Craig Sanders [EMAIL PROTECTED] writes: Craig why is application bar any *more* reliable or trustworthy Craig just because it is compiled against an old version of libc6 Craig in potato? It is not so much the new application I was thinking of, but all the old stable applications that already exist on the system. So recompiling foo for stable might produce a broken version of foo. fine. Downgrade or remove the package again. Problem solved. Nothing lost in the process, except time taken to down load, recompile and test the package. But installing a new version of libc6 on a stable system has the potential for breaking the whole system. ok, i see your point but don't think that libc6 is that much of a special case - any package has the potential to break the whole system. admittedly, some (libc6, ldso, bash, etc) more than others...but the potential is still there. IMO IME the biggest risk to a system running unstable is not so much bugs in libc6 or whatever, it's 1. bugs in package pre,post scripts: a simple typing error like rm -rf / var/spool/foo can wipe out a system (not that i've seen this one - i'm just aware of the possibility...so i upgrade non-vital systems first); and 2. faulty depends/conflicts or version mismatch (e.g. apache modules needing to be recompiled for major releases of apache) it gets even more interesting when you want an upgraded version of some application which depends on a newer version of some library which, in turn, depends on a whole bunch of other stuff including a newer libc6. what do you do then? do you recompile the whole dependancy chain (incl. libc6) for potato or do you say bugger it, it's less hassle and less risk to upgrade to unstable? at what point does recompiling for stable stop being a convenience for potato users and start being being a dead-end duplication of unstable? craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: support for older distributions
Russell == Russell Coker [EMAIL PROTECTED] writes:
Russell I would like a version of Potato that is not entirely
Russell frozen. It should have updates not only for security
Russell reasons but also for addition of new programs, and for
Russell adding new programs which add significant functionality
Russell and don't break things (such as Wichert's LDAP packages).
Another suggestion (one which you may not like, I haven't considered
it in to much detail):
Create a new Packages file for a new distribution (not sure what you
would call it) that lists stable Packages. Then once Y is convinced
that package X from {testing,unstable} runs OK, Y updates the new
Package file to include the new version of X. Any broken package
should not appear in this new distribution.
So it would be sort of like testing, only based around stable, not
unstable.
Pitfalls:
Of course, it goes without saying, that you can't copy the new package
into the new distribution until all dependencies have already been
satisfied. Including libc6 + libc6 related packages.
Also, I have not considered multiple architectures either.
Who is Y? What criteria is used?
--
Brian May [EMAIL PROTECTED]
Re: support for older distributions
Russell == Russell Coker [EMAIL PROTECTED] writes: Russell To manage this fully through the Debian system we will Russell need support in the BTS for reporting bugs to different Russell people depending on the package version. Is this Russell possible? Another problem which I consider a big issue, I think we need some way to keep track of different compiled versions. For instance, if I compile my own version of libx from unstable for my unstable system, and then run apt-get upgrade, apt will try (under various different situations) try to install libx-dev from unstable. However, this is wrong, because even though the version numbers match, libx-dev may contain static libraries which require the newer version of libc6. (not to mention different compile time options that could be used when compiling libx). So I really think there needs to be some way libx can say: Package: libx Build-Id: x where build is some unique identifier inserted at compile time. This could be similar to the Message-Id header on this E-Mail. Each time a package was compiled, it would get a different Build-Id. And then libx-dev can say: Package: libx-deb Depends: libx (= version [x]) which says libx-dev can only be installed with the libx version that was built at the same time. Actually, that could be simplified to Package: libx-deb Depends: libx (=[x]) as per my definition of build-id, if it is the same, the version must also be the same. Using this new syntax would only occur for special cases, eg. most (if not all) -dev packages. Of course, other methods are also possible (eg. insert depends of libx into depends of libx-dev), but this is my preferred option. You might even be able to use this new field to help the BTS tracking of packages somehow, but I haven't thought too much of this aspect. -- Brian May [EMAIL PROTECTED]
Re: support for older distributions
On Tuesday 08 May 2001 01:28, Chad C. Walstrom wrote:
On Mon, May 07, 2001 at 02:45:53PM +0200, Russell Coker wrote:
I would like a version of potato that is not entirely frozen.
...
I am willing to be involved in back-porting packages (there's many
things that I back-port for my own use and should share).
...
Also we have to consider the long-term view of this. I would
like to see back-ports to woody being done in a year's time...
It's not an easy request to address, really. Opinion is largely
subjective as to what one would find valuable for potato, and you run
into the problem of making slushy potato look more like woody. It's
a catch 22 if you take it too far.
I agree that it is a matter of opinion as to what is required. But if
someone is willing to back-port a package, and to maintain it (fixing any
bugs that may be reported against it), then why not make room on the archives
for it?
I think the long view on this subject focuses less on back-ports and
more on shorter release cycles. If we can get release cycles for
stable down to a year or less, back-ports would simply be less
important.
Even if we get release cycles down to less than a year there will still be
commercial considerations of the users. I can't install some serious Linux
servers for a company and say I'll be back before the end of the year to
upgrade everything!
So, contribute your efforts to improving and stabilizing woody, so we
can get it out the door! ;-)
Actually if it was easier to share work with other people who are forced to
back-port packages to Potato then I would have more time for working on
woody. My aim here is to spend less time working on Potato not more! The
more I can work with other people and share the load then the less work on
Potato I have to do.
On Tuesday 08 May 2001 09:28, Brian May wrote:
Another suggestion (one which you may not like, I haven't considered
it in to much detail):
Create a new Packages file for a new distribution (not sure what you
would call it) that lists stable Packages. Then once Y is convinced
that package X from {testing,unstable} runs OK, Y updates the new
Package file to include the new version of X. Any broken package
should not appear in this new distribution.
So it would be sort of like testing, only based around stable, not
unstable.
Pitfalls:
Of course, it goes without saying, that you can't copy the new package
into the new distribution until all dependencies have already been
satisfied. Including libc6 + libc6 related packages.
As for woody we are strongly encouraged to compile with the latest libc6
which means that such packages would never get into potato. That's just not
workable.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Re: support for older distributions
On Tue, 8 May 2001, Russell Coker wrote: But if someone is willing to back-port a package, and to maintain it (fixing any bugs that may be reported against it), then why not make room on the archives for it? Would there be any problem to just set up your own Debian-style site with BTS and apt-able archive, where people can contribute if they want and where you can semi-automatical merge in upstream (here Debian) updates (mostly critical bugs and security updates)? *t Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: support for older distributions
On Mon, May 07, 2001 at 02:45:53PM +0200, Russell Coker wrote: Currently there are two usable repositories of Potato packages. There's a repository of kernel-related packages to run 2.4.x kernels on Potato, and there's a repository of LDAP related packages and other things that Wichert is maintaining. Both of these are good work, but even combined they don't provide what I consider to be adequate support for Potato. I would like a version of Potato that is not entirely frozen. It should have updates not only for security reasons but also for addition of new programs, and for adding new programs which add significant functionality and don't break things (such as Wichert's LDAP packages). why? aside from the installer floppies (which aren't relevant for upgrades), the main significant difference between potato and woody (or between any versions of debian for that matter) is the version numbers of the packages included. the distinction between versions of debian is entirely arbitrary, a matter of consensus reality rather than actual reality. your suggestion would add a huge load of administrative and maintainence overhead in order to support a convenient fiction - providing little or no real benefit. worse than that, it subverts the only real point in having versioned releases - the ability to know what is included in any released version. debian provides mechanisms for easy upgrade between release versions, and we always have provided that - why complicate matters with branched sub-releases of old versions? you also risk creating greater problems back-porting packages from testing or unstable - they would be divergent packages which don't get anywhere near the same amount of testing and usage as packages in the mainline development cycle. for example, ask yourself: why is libc6-2.2.2-potato1 (or whatever the potato version would be) any better or safer than just installing libc6-2.2.2 from woody or sid? i can't see how it could be, and all you've achieved is having two divergent versions of 2.2.2 to support. debian is a live distribution, easily upgraded in place at any time over the internet - why limit yourself to looking at debian in a way which is more suited to commercial CD-ROM only closed source systems? IMO, forcing debian into that model is missing a large part of the point of debian. potato's been released. woody's getting closer to freeze. lets move on. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: support for older distributions
On Tue, 8 May 2001, T.Pospisek's MailLists wrote: Would there be any problem to just set up your own Debian-style site with BTS and apt-able archive, where people can contribute if they want and where you can semi-automatical merge in upstream (here Debian) updates (mostly critical bugs and security updates)? *t I just got my ISP bill for the last month and in one word, ouch! A good deal of the bandwidth is used up by the unofficial potato packages I maintain for uw-imapd and webmin. I'm not going to stop offering them, I'll just move them to people.d.o or even sourceforge or somewhere but it would save users a lot of aggravation if there were one central place for this kind of thing. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: support for older distributions
i have libssl openssh 2.5.2p2 for potato at http://people.debian.org/~ieure/potato_ssh On Mon, 7 May 2001, Russell Coker wrote: Currently there are two usable repositories of Potato packages. There's a repository of kernel-related packages to run 2.4.x kernels on Potato, and there's a repository of LDAP related packages and other things that Wichert is maintaining. Both of these are good work, but even combined they don't provide what I consider to be adequate support for Potato. I would like a version of Potato that is not entirely frozen. It should have updates not only for security reasons but also for addition of new programs, and for adding new programs which add significant functionality and don't break things (such as Wichert's LDAP packages). To manage this fully through the Debian system we will need support in the BTS for reporting bugs to different people depending on the package version. Is this possible? Also we need space to maintain the packages (they shouldn't be THAT big). The aim should be that the maintainer of the woody version should not need to be involved in the backports (unless they want to be involved). I am willing to be involved in back-porting packages (there's many things that I back-port for my own use and should share). Also we have to consider the long-term view of this. I would like to see back-ports to woody being done in a year's time...
Re: support for older distributions
On Mon, May 07, 2001 at 02:45:53PM +0200, Russell Coker wrote: I would like a version of potato that is not entirely frozen. ... I am willing to be involved in back-porting packages (there's many things that I back-port for my own use and should share). ... Also we have to consider the long-term view of this. I would like to see back-ports to woody being done in a year's time... It's not an easy request to address, really. Opinion is largely subjective as to what one would find valuable for potato, and you run into the problem of making slushy potato look more like woody. It's a catch 22 if you take it too far. I think the long view on this subject focuses less on back-ports and more on shorter release cycles. If we can get release cycles for stable down to a year or less, back-ports would simply be less important. So, contribute your efforts to improving and stabilizing woody, so we can get it out the door! ;-) -- Chad Walstrom [EMAIL PROTECTED] | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD pgpJiiJ72kfIV.pgp Description: PGP signature
Re: support for older distributions
Hi, At Mon, 7 May 2001 09:51:24 -0700 (PDT), Ian Eure wrote: i have libssl openssh 2.5.2p2 for potato at http://people.debian.org/~ieure/potato_ssh Good job. If you execute 'dpkg-scanpackages . /dev/null | gzip -9 Packages.gz' in this directory, we'll be more happy :-) -- Kenshi Muto [EMAIL PROTECTED] pgpoMpWk21qMB.pgp Description: PGP signature
