Colin Watson wrote:
In the first example, the fact that foo depends on bar while
simultaneously conflicting with the version of bar in the suite you're
looking at is the thing that's bad, because it means foo can't be
installed. The second example is OK, even though foo and bar can't be
Steve Langasek wrote:
Ok. BTW, are you taking into account the possibility of a package being
uninstallable due to versioned Conflicts, and Conflicts between packages
which otherwise satisfy a package's dependencies?
No, not yet. I will look into it.
--
Björn
Steve Langasek wrote:
The term metapackage is a gratuitous label, here. There is a real
binary package (as opposed to a virtual package) in the archive named
gcc, which comes from the gcc-defaults source package; and its
versions are handled just like those of any other packages.
Ah, silly
Steve Langasek wrote:
Hypothetical example:
29 packages wait on (151 packages are stalled by) libxml2. This package
is too young, and should be a valid candidate in 8 days.
Suppose that the libxml2 source package provided not only the
libxml2-python2.3 binary package, but also a
Steve Langasek wrote:
Yes, I refer to these lists frequently. :) Thanks for putting these
together!
Thanks for using them. ;)
Yep, and libxml2 is also a dependency of libxslt. But of course,
neither of these are packages that need direct attention; the one is
held up waiting for the
Steve Langasek wrote:
What's hard to see at a glance is how large collections of packages are
interrelated in their dependencies. Many packages that you *don't* use
may be having a direct effect on the packages you *do* use as a result
of their bugginess. I'd like to be able to make as much
Andreas Rottmann wrote:
I wonder why yehia isn't entering testing. According to [0] it makes
qmailmrtg7 uninstallable, but qmailmrtg7 is totally unrelated to
yehia, AFAICS.
Regards, Andy
[0] http://bjorn.haxx.se/debian/testing.pl?package=yehiaexpand=1
I've been on vacation, during which
Gerfried Fuchs wrote:
Yes, I've read the testing page with the FAQ and both the
testing_excuses and testing_output, but I can't see the reason why
libsidplay doesn't enter testing.
I've written a little script that tries to answer precisely this type of
question. You can run it here:
Gerfried Fuchs wrote:
Thanks for the great script. It shows me that the testing script seems
to be buggy, because:
- Updating sidplay-base makes 1 packages uninstallable on alpha:
sidplay-base
Uhm, that is somehow nonsense. How can an update of a package make
itself
Joe Buck wrote:
However, the output is redundant in many cases.
Fixed now.
--
Björn
Manoj Srivastava wrote:
This is, after all, more than just a herd of cats.
How on earth did you get that quaint idea?
From looking at Debian. It is far more structured, organised and controlled
than the great majority of free software projects out there.
If you want a universally held firm
Keegan Quinn wrote:
Funny how myself and every admin I know have only very minor issues with
running unstable. What, pray tell, makes it such an 'obvious' non-option
for end users?
How about constantly repeated statements to the effect?
So you did not even look at the release announcement,
Michael Stone wrote:
All the complaints we see every couple of weeks about testing would be swept
away if people followed this advice and simply didn't use testing.
This brings back the question I never got an answer for: Who is Debian for?
If only stable and unstable are supposed to be used,
Manoj Srivastava wrote:
On Wed, 14 May 2003 15:16:38 +0200, Björn Stenberg [EMAIL PROTECTED] said:
This brings back the question I never got an answer for: Who is
Debian for?
Isn't is obvious? Me, of course. Y'all are working to provide
a stable environment for my machines at home
Matt Zimmerman wrote:
There is no shortage of opinions about what we should do, but there is
unlikely to be any action until an I arises who actually does the work.
Of course, but it's still important to discuss what should be done. Show me
the code is only a useful response if anyone in the
Don Armstrong wrote:
Debian will always be for whoever the people contributing to Debian
are willing/want it to be for. No more, no less.
Naturally, since it's free software. But saying Debian is what we make it
doesn't answer the question what you _want_ it to be, only what has been done.
Theodore Ts'o wrote:
So let me make the following modest strawman proposal. Let us posit
the existence of a new distribution, which for now I'll name
testing-x86.
I suggested the same thing a few weeks ago, with little reaction. Nice to see
someone else got the same idea.
I'd volunteer to
Manoj Srivastava wrote:
Testing is a release tool. Not a distribution for random end
users to run.
That is rather different from what is written on the web site:
For basic, user-oriented information about the testing distribution, please
see the Debian FAQ. (/devel/testing)
testing
The
Matthias Urlichs wrote:
If I understood correctly, part of the problem is/was that some of the
rebuilds simply didn't work because of problems with the new compilers.
The current tools don't allow programs of arch X into testing if they fail to
build on arch Y. I think that in general this
Stephen Ryan wrote:
there is no substitute for testing in the *exact* environment that you
plan to release in. Period.
My point exactly. We should test packages in the environment we plan to
release: sarge. We should not let new uploads hold other packages
hostage. Because then we are only
Roland Mas wrote:
To me, you seem to express the view that improving Debian means
throwing away our release process, including the way testing works.
Then I have expressed myself unclearly. My apologies. I think testing is a
great idea and a most necessary institution. In fact, I wish we had
Matthew Palmer wrote:
Perhaps one reason is that fixing enough bugs to get stuff into testing is
currently a whack-a-mole job?
I don't think your proposals will really fix that, since in my experience
that new version of A probably requires all sorts of new crap from B
anyway...
Does it,
Matthew Palmer wrote:
it's labour-intensive, it's pretty damn effective.
^
And there's why it doesn't work for Debian. We don't have money to throw at
our developers.
I never claimed we should. I merely explained one of the many reasons Debian
is fundamentally slower
David Nusinow wrote:
You say you can't deal with unstable because the software is broken.
Well, that's because the software you want isn't ready to be released.
That's not the whole truth. A _lot_ of software is ready and working, but is
held back from entering sarge due to dependency problems
Simon Huggins wrote:
I have a feeling you want to discover update_output.txt
Thanks, I have looked at it before but apparently not enough. Some followup
questions:
update_output.txt says:
trying: cfitsio
skipped: cfitsio (1144+9)
got: 13+0: a-4:a-9
* arm: fv, libcfitsio-dev,
Rene Engelhard wrote:
4) What is the best way to find out why cfitsio depends on gcc-3.3?
looking in the Packages files?
(do in on auric directly or d/l them and do it at home)
Where can I download these files? (Packages is a tricky word to search for...)
Thanks.
--
Björn
Hi.
I'm trying to understand the dependency system so I can find the complete and
correct answer to questions in the form why is the latest version of package
X not in testing yet. I've been annoying some of you with wrong assumptions
previously, sorry about that. I'll avoid that this time and
Colin Watson wrote:
The reason why a library's shlibs get changed
is that binaries built against one version of the library can't be
guaranteed to run correctly against older versions.
Because the interface changed or because the previous version was buggy?
I have always assumed the first
Colin Watson wrote:
forcing other packages to always depend on the latest version of them
No, that's not what shlibdeps do.
Right, it does not force the latest, only the version that is installed on
the machine it runs on. But isn't the effect essentially the same, since most
people/robots
Colin Watson wrote:
No, that's not what shlibdeps do either. See:
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps
Lovely, so it's simply the other way around (as Adam Conrad said already).
Thanks.
However, it still means packages get bogus dependencies
Matthias Urlichs wrote:
Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ...
Note that the version shown is simply the current libgcc.so version.
Current as of when? When the upload was done?
dpkg-shlibdeps has no idea whether an older version would be sufficient,
so it plays safe.
Jim Penny wrote:
Björn Stenberg wrote:
Isn't this a problem? Especially for packages depending on libraries with
long release cycles, such as libgcc1 and libc6.
Not often. Most slow release libraries are strongly backwards
compatible.
That was my point. Since these libs are strongly
Bob Proulx wrote:
Just minor searching through the archive turned these up with relevent
discussion.
These posts, as your reply in debian-testing, concern packages that are not
Valid Candidates.
My question concerns perfectly working packages that are suitable for testing,
yet are never
Anthony Towns wrote:
You'll find it does on arm and probably one or two other architectures,
but in particular:
Package: libcurl2
Architecture: arm
Version: 7.10.4-1
Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ...
Sorry for being a pain, but how are these
Hi.
(I first submitted this question to debian-testing, but was referred here for
discussion.)
I have been looking at the excuses page[0] and was struck by how very old
some packages are in testing, yet only the very latest bleeding edge version
from unstable appears to be considered for
35 matches
Mail list logo
