Re: Bootstrapping: list of 81 self-cycles in Debian Sid
On 03/05/2013 10:46 AM, Johannes Schauer wrote:
Hi,
Quoting The Wanderer (2013-03-05 15:35:37)
You can build either one without a matching version of the other, but you
won't get full functionality. In order to get the full functionality of
both, from what I've been able to tell you need a minimum of three builds
on every cross-matching-version update: x264 without libavformat support,
then FFmpeg with x264 support, then x264 with libavformat support. (Or
possibly the reverse, but x264 is faster to build than FFmpeg is.)
Assuming you build x264 without libavformat, the correct order is actually:
1. src:x264 without libavformat-dev
2. src:libav fully
3. src:x264 fully
4. src:libav fully again
We add the fourth step so that it is less likely that a libx264-dev with
limited functionality influences the binaries built by src:libav in some
funny way.
That's reasonable, yes. I haven't needed it in my private builds (tracking the
respective git trees), but it's a good take-no-chances safety step.
At a glance, this looks to me like a variant of the self-cycle problem. Is
it something which should/could be addressed as part of the same effort? Or
is it already handled in Debian in a way I haven't noticed? Or "none of the
above"?
Maybe I didnt understand you correctly but maybe it helps if I note that the
example you give is not a self-cycle but a cycle of length two (or four
depending on the type of dependency graph).
In that case, this (part of it) is a problem with my misunderstanding the
terminology being used.
I was understanding "self-cycle" as being a simple shorthand for "any dependency
cycle in which compiling a given package ends up depending on having that
package already installed". If it's actually being used in a more techically
specific sense here, then I should have used a different term.
Go to this wiki page:
http://wiki.debian.org/DebianBootstrap/TODO
And search for this string:
src:libav -> libx264-dev -> src:x264 -> libavformat-dev
This is the cycle that you took as an example earlier. So yes, we can also
find those cyclic dependencies but they are a different problem class because
instead of having just one way to break them, there are now two:
Thank you.
On the face of it this doesn't seem to address the question I was actually
trying to ask (does this cycle-detection effort also detect "soft" dependencies
which simply result in reduced functionality, as well as ones which result in
build failures?), but the fact that this particular "soft" dependency is
included in that - presumably automatically-generated - list implies that the
answer is "yes".
That's all I was concerned about; thank you, and keep up the good work!
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
Reply to: