| |||||||||||||
Revealed: how Fedora and the community interactRevealed: how Fedora and the community interactPosted May 4, 2004 23:41 UTC (Tue) by tjc (subscriber, #137)In reply to: Revealed: how Fedora and the community interact by JoeBuck Parent article: Revealed: how Fedora and the community interact But woody is so old as to be useless, unstable is too unstable (a sid update broke ssh recently, which is a complete disaster when you can't get to your system remotely), and until recently sarge systems tended to be inconsistent (half of an older Gnome or KDE and half of a newer one). It seems like there's a place for a 4th version of Debian between unstable and testing. Maybe based on unstable, but a week or two behind in the updates. This way when something bad happens, like a broken X server, there's time to fix it before it propogates to "semi-unstable." Is there any provision for telling apt to delay updates for x number of days? If there is/were, that would be a nice way to control the "unstableness" while still using the same repository.
(Log in to post comments)
Revealed: how Fedora and the community interact Posted May 5, 2004 0:21 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] No, Debian doesn't have the cycles to support yet a fourth version. Better to just focus on getting sarge finished.
Revealed: how Fedora and the community interact Posted May 5, 2004 3:03 UTC (Wed) by rfunk (subscriber, #4054) [Link] Maybe based on unstable, but a week or two behind in the updates. This way when something bad happens, like a broken X server, there's time to fix it before it propogates to "semi-unstable." You just defined the testing branch of Debian.
Revealed: how Fedora and the community interact Posted May 5, 2004 17:04 UTC (Wed) by tjc (subscriber, #137) [Link] You just defined the testing branch of Debian.Some of the packages in "testing" are months behind unstable. I'm looking for a delay of one or two weeks, not months.
Debian testing Posted May 5, 2004 17:32 UTC (Wed) by rfunk (subscriber, #4054) [Link] Some packages in testing are months behind because either the newerversions have "release-critical" bugs keeping them out, or they have dependencies that either haven't been in unstable long enough (or at all) or that themselves have release-critical bugs. Those dependencies are always the killer..... And if you're going to just unconditionally stick something in testing after being in unstable for a week, you're losing the benefits of that week delay in the first place.
Debian testing Posted May 5, 2004 18:47 UTC (Wed) by tjc (subscriber, #137) [Link] And if you're going to just unconditionally stick something in testing after being in unstable for a week, you're losing the benefits of that week delay in the first place.I'm not suggesting sticking anything in "testing." What I am suggesting is adding capabilities to apt so that updates can be delayed for x number of days in the hope that major problems can be avoided. This would not require an additional branch. Think of it as following someone on the highway 4 or 5 seconds behind, instead of right on their back bumper.
Debian testing Posted May 5, 2004 19:29 UTC (Wed) by rfunk (subscriber, #4054) [Link] I'm not suggesting sticking anything in "testing." The mechanism isn't important. You're talking about client-side smarts vs server side smarts, but the end result of what's installed on the system is really the important thing.
What I am suggesting is adding capabilities to apt so that updates can be delayed for x number of days in the hope that major problems can be avoided. But you need to do more than hope if you're going to avoid major problems. During that x number of delays, major problems may be found, but they may not be fixed yet. What you're proposing is to go ahead and get those packages even with known major problems, rather than wait until those major problems are fixed.
Debian testing Posted May 5, 2004 21:57 UTC (Wed) by tjc (subscriber, #137) [Link] The mechanism isn't important.Yes it is. If capabilities are added to apt, then there is no additional maintanance for the pool. It gets the same files, just delayed by an interval selected by the user. What you're proposing is to go ahead and get those packages even with known major problems, rather than wait until those major problems are fixed. No, that's not it either... What I would like is some time to find out that a problem exists before I install a package. If I could hold updates back for a week or two, that would provide some time for major problems to become known. Finding out that a package is messed up after it has been installed it isn't all that helpful.
Debian testing Posted May 6, 2004 9:47 UTC (Thu) by boomi (guest, #21418) [Link] > Finding out that a package is messed up after it has been installed it isn't all that helpful._Someone_ has to find out. If you use unstable, you agree to help discover bugs in new packages. Use testing if you don't want to do that. Btw: old packages are stored in /var/apt/ archives, you can easily restore an old version. Using unstable? You are asking for trouble. Which is a good thing, someone else won't have the
Debian testing Posted May 6, 2004 15:20 UTC (Thu) by tjc (subscriber, #137) [Link] If you use unstable, you agree to help discover bugs in new packages.I don't recall entering into any such agreement. :-) Use testing if you don't want to do that. Testing is too old for my taste. By the time it becomes stable, it will be nearly obsolete. It's sort of the worst of both worlds in that respect. There's a big gap between "testing" and "unstable." It's within this gap that Fedora Core and Mandrake exist. Debian could probably increase the size of their user base by a significant amount by filling this gap. Personally, I use "unstable" on my workstation, but I keep a partition with Fedora Core around in the event that "unstable" becomes too much of an adventure. I wait for the dust to settle, and come back in a week or so. This happens about once a year.
Debian testing Posted May 10, 2004 9:55 UTC (Mon) by mbanck (subscriber, #9035) [Link] There's a big gap between "testing" and "unstable."I don't believe this is true right now. The release team is doing a great job nowadays resolving problems in testing when two packages keep each other out and so. It used to be quite bad when only AJ was looking after testing, but since we have a couple of very bright "Release Lieutenants", things are moving quite well. For example, it used to take a new glibc package months to enter testing. Last week, 2.3.2.ds1-12 entered testing after being in unstable for just two weeks or so. I agree that stable might be too old for desktop use (I have to use it myself at work), but testing is only lacking behind only for some corner-cases, while it is quite uptodate in general. Michael
Quit it... there is a solution to both your qualms. Posted May 6, 2004 19:49 UTC (Thu) by gfolkert (guest, #21427) [Link] http://snapshot.debian.net/ apt-get debian packages on specified date (relative date)deb http://snapshot.debian.net/archive/date/datestr/debian unstable main contrib non-free deb http://snapshot.debian.net/archive/date/datestr/debian-non-US unstable/non-US main contrib non-free deb-src http://snapshot.debian.net/archive/date/datestr/debian unstable main contrib non-free deb-src http://snapshot.debian.net/archive/date/datestr/debian-non-US unstable/non-US main contrib non-freeNote that datestr is datestr recognized by date(1), such as yesterday, 2-days-ago, last-week, 2-weeks-ago. You will get everything JUST like you want.
Quit it... there is a solution to both your qualms. Posted May 6, 2004 21:47 UTC (Thu) by tjc (subscriber, #137) [Link] OK, now that's what I was looking for! Thanks.
Quit it... there is a solution to both your qualms. Posted May 10, 2004 12:03 UTC (Mon) by zigg (guest, #14265) [Link] Okay, that's just plain nutty. You get all the same bugs, all the same uninstallable packages, all the same horking -- just two weeks later than everyone else. The only possible advantage you can have is that maybe there might be a fix in two weeks that you can go and pull from unstable.After gnucash broke last time, I moved to testing. It works. It is not "behind" in any way that causes me any kind of trouble. I pulled one package from unstable -- kernel 2.6.5, to support my wireless card -- and even that is in testing now. Testing is what you want.
Revealed: how Fedora and the community interact Posted May 6, 2004 9:48 UTC (Thu) by angdraug (subscriber, #7487) [Link] There always is a reason for that: http://bjorn.haxx.se/debian/testing.pl
Revealed: how Fedora and the community interact Posted May 5, 2004 8:52 UTC (Wed) by evgeny (guest, #774) [Link] > Is there any provision for telling apt to delay updates for x number of> days? If there is/were, that would be a nice way to control the > "unstableness" while still using the same repository. There is apt-listbugs apt plugin which fetches bug reports for packages before installation and in case there are critical ones lets you decide what to do. For me, it reduced the apt-get upgrade headaches significantly. It would be nice yet to tell it to wait for a minimal delay (unless this is a security update) to allow for bug reports to flow in. It could be a separate (from listbugs) plugin.
Revealed: how Fedora and the community interact Posted May 5, 2004 17:07 UTC (Wed) by tjc (subscriber, #137) [Link] There is apt-listbugs apt plugin which fetches bug reports for packages before installation and in case there are critical ones lets you decide what to do.Thanks for the info - I will install apt-listbugs and give it a try.
Revealed: how Fedora and the community interact Posted May 5, 2004 17:09 UTC (Wed) by razholio (guest, #5706) [Link] 'But woody is so old as to be useless'*sigh* I maintain several woody servers doing radius, SMTP, IMAP, POP3, HTTP, HTTPS, SSH, SAMBA, DHCP, HTTP proxy and others... I enjoy the fact that these systems are up-to-date on security fixes (that never break anything) within hours of public disclosure, are rock-solid stable and make my life as an administrator rediculously easy. I have chosen to compile a couple apps, although i didn't *have* to. I can't imagine another distro on my servers. I have woody on my workstations too, although here I've had to do more work with several backports in /etc/apt/sources.list and lot's of stuff compiled from source (although usually the ./configure&&make&&make install three-step is faster than my co-worker's search for a fedora compatible RPM!). There are those times when I look at fedora, but they are infrequent for sure.
|
|||||||||||||