Re: User-contrib, up-to-date stable
Hi,
>>"Michael" == Michael Stone <mstone@itri.loyola.edu> writes:
Michael> Quoting Manoj Srivastava (srivasta@datasync.com):
>> The way it is set up, people may just download sources from hamm,
>> if they are sure the packages would live happily on bo as well, and
>> try ./debian/rules binary. If that works (producing a deb file),
>> and they just feel lucky ;-), they can upgrade the package
>> piecemeal.
Michael> What's the advantage of getting and compiling a hamm package
Michael> over just grabbing the original tarball and compiling? Most
Michael> of the stuff I see nowadays has a ./configure and a
Michael> relatively simple make procedure...
<Incredulously> what was the last time you did that for a
significant number of packages? I used to run a home brewed system
before I moved to Debian (I initially installed SLS at Linux v0.94 or
so, and upgraded piecemeal by hand until I moved to Debian).
There is a significant amount of work required to compile and
configure a lot of the packages, configure script or no. And lots of
packages do not come with scripts. Also, most breakages are not
upstream bugs, they are configuration errors, and a Debian source
comes with most of that work done for you.
Add to that that you get dpkg and friends to know that you
*have* installed the package, and to upgrade when 2.0 comes around,
it's no contest. Trusat me, you do not want to maintain a home brewed
system, even if it is mostly in /usr/local.
All you have to do is add an entry in the debian/changelog
file (changing the version number by suffixing a .01), and running
./debian/rules binary, and installing the package (if you are
lucky). If you are not lucky, you are probably closer than starting
from raw upstream sources.
Michael> Quoting Hamish Moffatt (hmoffatt@mail.com):
>> In short, can you really have a current system labelled "stable"?
>> It may be stable, but it needs time to prove itself ...
Michael> How much testing decides whether a package is stable? If
Michael> there's a large amount of upstream testing, and it will run
Michael> on the debian system, how much of a delay is justified? In
Michael> other words, where's the break even point between the benefit
Michael> of fixing _known_ bugs and the risk of introducing _possible_
Michael> bugs?
These questions are better asked of the qa group. Anybody
listening? Also, I think that past experience kinda militates against
the concept of "large amount of upstream testing". I think that the
free software paradigm has always been that the endusers are part of
the testing process; and I think that people who run stable have been
shielded by the (stellar) work of the qa group. Unfortunately, if
they do their job well, nobody notices them.
I find it facinating that the same group of people who find
unstable "too bleeding edge" are advocating a faster movement
of packages so that they become available for stable runners. I know,
I know, the argument is that only ``select'' packages will be
upgraded. There are few packages that have not broken the system
badly in their debian history; no matter how select you are; Thats
why we have unstable. Anyway, anything may break badly in the next
release.
manoj
--
"Obedience. A religion of slaves. A religion of intellectual death.
I like it. Don't ask questions, don't think, obey the Word of the
Lord -- as it has been conveniently brought to you by a man in a
Rolls with a heavy Rolex on his wrist. I like that job! Where can I
sign up?" Oleg Kiselev,oleg@CS.UCLA.EDU
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: