Re: A real case.
> joost witteveen wrote:
> >
> > (I didn't read all of the 10 page document)
>
> You couldn't because there were only 3 pages (exacly as your short
> reply); the other 7 was eated up by the antispammer :-)
>
> >
> > My comment would be:
> > Any programmee that uses libraries from unstable is infact itself
> > unstable too. (Use a library, you use code that come from that
> > library, and that code we consider "unstable", if the librarie
> > comes from unstable and thus hasn't been tested as much as stable).
>
> Nope.
> You are confusing the "unstableness" of a debian package with that of
> its content. When an Author releases an upgrade version of a library,
> after some time of testing, and declares it as "stable" why should other
> Authors wait for debian to release "unstable" as "stable" just to use
> the library?
Because _we_ cannot be sure that stable, and totally bugfree library
doesn't expose bugs of other packages, or do other neasty things.
Also, we cannot be sure the debian maintainer didn't add bugs in
the debian/* files. That's why it should go into unstable. Only if there
are _very_ strong reasons why it should go into stable, then we might
consider it. But by default, every new release of every BugFree package
should go into unstable. That's just our definition of stable/unstable.
> A debian package moves from "unstable" to "stable" (as long as all the
> others) due more to schedules that to effective stability.
> When I started maintaining groff I released the new upstream version
> that had been sitting on the gnu site for more that one year. The
> package went to unstable but that version of groff was surely stable!
No. It wasn't tested by debian, it wasn't stable, perioud.
First of all, bugs may prop up that are very debian specific. I don't
think many other distributions for example use excactly our libc5 version.
And then, even though I'm sure your debian/* files are BugFree, you
still need to find a way to convince the testing team that whatever
you write is BugFree, and doesn't need to be tested. I'm afraid
the testing team doesn't trust you as much as you do yourself, and
they will want to test your BugFree debian/* files.
> > Thus, why on earth does the author think his package belongs in
> > stable? It's well and truley unstable.
>
> He doesn't think it "belongs" to stable. He wants they user use it, and
> those users are running stable, not unstable.
Then he'll have to wait till we release unstable as stable.
For example, I'm absolutely sure fakeroot 0.1-0a has no bugs
whatsoever (well, it's been out for one day already, and nobody
but myself found any bugs, it must be bugfree). But I don't mind it
not being in stable.
>
>
> > I'm sure that if that message is then posted to debian-devel, and
> > the programme is usefull, there will be developpers that show up and
> > package up his programme for unstable.
>
> Thus demonstrating the ugly assertion that "you need do be a debian
> developer to make .debs".
No, it's the other way around. When you make .debs, you more or less
_are_ a maintainer (appart from some ID formalities). Now, I don't
think that's an ugly assertion at all!
> > To summerise: a programme that has just been released by the author
> > doesn't belong in stable! It belongs in unstable. If the author
> > doesn't run unstable, then s/he should find somebody else who does
> > run unstbale.
>
> you have completely forgotten user's roll.
> Users are asking to the Author to release a .deb package for their
> "stable" systems.
I haven't completely forgoten anybody at all.
I just say that adding to stable just released programmes, that need
(as in your case) just released libraries is just plain stupid.
If we allow that as a rule, next thing we know is that those libraries
depend on new versions of gcc, and gcc depends on new versions of libc,
and, and so on. And then, there's no difference between unstable and
stable. So, all you are arguing for is to for stable to be more like
unstable.
Well, it could be arguable to add another tree, like
stable
nearlystable
unstable
and then "nearlystable" would be the "stable" that you basically want.
But then what do we tell the developpers to upload to "nearlystable"?
By your definition, all new libraries need to go directly into
"nearlystable". (Your problem excactly started with a application that
depended on recent versions of libraries). And, with those new libraries,
go the latest versions of, well, everything. So, I don't really see
the difference between what you want to be "nearlystable" and "unstable".
OK, the only difference could be to ask the developpers to "please, only
upload anythign that you _think_ will not break anything to nearlystable".
But I'm sure that holds to 99% of uploads to unstable at the moment.
For example, the xlib6g upload was one that probably should have gone
to "nearlystable". And, infackt it has proven relatively bugfree. Except
that it showed bugs in fvwm2, emacs, .., causing those apps to segfault.
Should xlib6g have been uploaded to "nearlystable"? I don't know.
On the other hand, I could envisage a situation where a group of people,
who are running "unstable" constantly, test out the uploads, and
deside what packages are relatively stable, and what are truely unstable.
Then we could have that group of people to move the releatively stable
packages to "nearlystable". This might work, but it will require
a group of people to continually do work on that. And, I don't think
their task is very easy: For example, the xlib6g problem: should they
approve it or not? And, I'm sure there are more.
> But I agree that the bst way is to release a statically linked program.
> The best way from debian's perspective, not for user's resources.
Or package up the libraries too, along with the programme.
--
joost witteveen, joostje@debian.org
#!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
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: