On 2012-05-12 00:46, Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>> In that approach, as mentioned before
>> the binary packages should include a special field so the archive
>> knows to reject them.
>
> Could you give some examples of differences between a stage1 build and
> a full build that this procedure might be able to accomodate? I know
> skipping documentation processing steps might be one common trick; I'm
> trying to figure out if more serious changes in the functionality
> provided by a package might be involved.
A staged binary package may indeed have limited functionality relative
to the full package. Many packages can be built without some of their
dependencies â they might be configured to not link against certain
libraries or to not execute certain utilities during build time or run
time. In many cases it is useful to build packages without these
optional ("soft") build dependencies to break dependency cycles â
resulting in a smaller set of binary packages and/or binary packages
with limited functionality.
> What happens if my program grows more complicated and I need to add a
> step that produces an even more limited package before what was
> previously the stage1 build? Do the stages of all other packages with
> staged builds using my program have to be renumbered to make room?
Except for toolchain packages, there are so far no known cases in the
archive where more than one stage is necessary.
If a package becomes more complicated (e.g. introduces a library
dependency that would create a build dependency cycle), then that could
most likely be handled by simply not adding the new build dependency/ies
to "Build-Depends-Stage1".
If there is indeed a case in which that isn't sufficient and a new stage
is necessary as you propose, then yes, the stages must be renumbered in
debian/control and debian/rules.
--
P. J. McDermott (_/@\_) ,--.
http://www.pehjota.net/ o < o o > / oo \
http://www.pehjota.net/contact.html o \ `-/ | <> |.
o o o "~v /_\--/_/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
