Re: Bootstrapping: list of 81 self-cycles in Debian Sid
At risk of making myself look like an idiot, I have a possibly contributory
question.
On 03/05/2013 06:22 AM, Johannes Schauer wrote:
Self-cycles can be divided into two classes:
1. a build dependency on a binary package the source package builds (the
simple case)
2. a build dependency on a binary package which needs one of the binary
packages the source package builds to be installable
I'm not sure if this is something you want to include in scope here, but what
about functionality dependencies? That is, what about cases where you can build
successfully without the dependency, but you will end up without some desired
functionality as a result?
For example, building FFmpeg (which provides libavformat) with x264 support
requires that a new-enough-to-be-compatible version of the x264 libraries
already be installed. However, building x264 with libavformat support requires
that a similarly new-enough-to-be-compatible version of libavformat already be
installed. In my experience, in both cases, "new enough" frequently seems to
mean "the version of the other you're already trying to build".
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.)
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"?
--
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: