Can we require build-arch/indep targets for lenny? - Debian

This is a discussion on Can we require build-arch/indep targets for lenny? - Debian ; Loc Minier writes: > On Tue, Jun 26, 2007, Joey Hess wrote: >> I think it would also be useful to include 'nostrip' and 'noopt' in the >> Build-Options field, as a way to indicate that the package implements >> ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 65

Thread: Can we require build-arch/indep targets for lenny?

  1. Re: Can we require build-arch/indep targets for lenny?

    Loc Minier writes:
    > On Tue, Jun 26, 2007, Joey Hess wrote:


    >> I think it would also be useful to include 'nostrip' and 'noopt' in the
    >> Build-Options field, as a way to indicate that the package implements
    >> those DEB_BUILD_OPTIONS. I also have some Evil Plans for other things
    >> that can go in Build-Options, but they're not ready yet and would be OT
    >> in this thread.


    > Why not promote these to requirements in a particular policy version
    > instead? I fear we will have to list 10 Build-Options in all packages
    > in a couple of years.


    Currently, policy says that it's recommended (the weakest policy
    directive) to support noopt and nostrip. My main concern with increasing
    the strength of that directive is that, depending on how demented the
    upstream build system is, it can be difficult to support these options,
    and since neither is used for regular builds in Debian, they're not
    usually tested and aren't necessary for properly functioning packages.

    --
    Russ Allbery (rra@debian.org)

  2. Re: Can we require build-arch/indep targets for lenny?

    Russ Allbery writes:

    > Currently, policy says that it's recommended (the weakest policy
    > directive) to support noopt and nostrip. My main concern with increasing
    > the strength of that directive is that, depending on how demented the
    > upstream build system is, it can be difficult to support these options,
    > and since neither is used for regular builds in Debian, they're not
    > usually tested and aren't necessary for properly functioning packages.


    I have a little bit of experience with recompiling packages to
    include debug symbols. In that little of experience I found that
    the easiest way to do it was to put a set of wrapper programs in
    $PATH that ensured that compilers added debug symbols and that
    programs and options to remove them were ignored. I wonder
    whether this general approach would be better than requiring each
    package maintainer to implement a pair of build-time options.
    The most obvious trouble I can see with it is packages that
    invoke tools through absolute paths or reset $PATH themselves.

    (I haven't followed previous discussion of these options. If
    this approach has already been considered and discounted, please
    ignore me.)
    --
    Ben Pfaff
    http://benpfaff.org


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: Can we require build-arch/indep targets for lenny?

    On Mon, Jun 18, 2007 at 10:30:55AM +0200, Goswin von Brederlow wrote:
    > I would like to gather up some momentum for a policy change. Namely
    > that the build-arch/indep targets in debian/rules become required
    > instead of being optional.


    > The reason for this is that dpkg-buildpackage can't reliable detect
    > the existance of the build-arch/indep targets and must call 'build'
    > instead. This forces every source to compile both architecture
    > specific and architecture independent code on all buildds and
    > increases the Build-Depends of packages a lot.


    > Current status:


    > I asked Lucas Nussbaum to rebuild all of debian with dpkg-buildpackage
    > patched to call 'build-arch'. Here is the result:


    > 7326 packages rebuilt (all packages not Architecture:all)
    > 1727 built successfully
    > 5463 failed to build with a "no rule to make" error.
    > 136 failed for other reasons (unsat builddeps, etc)


    > That means that only about 25% of debian package have a build-arch
    > target. So there is still a long way to got.


    > Possible upgrade paths:


    > 1) Change policy now making 75% of package RC buggy instantly.


    > This sounds horrible but the fix is trivial and there is still a
    > long time to lenny to fix it.


    No, the fix is not trivial; you will not get the buildd maintainers to
    implement such a change when it makes 75% of the archive unbuildable, and
    without such pressure you will never reach 100% adoption by package
    maintainers.

    Any serious adoption path needs to get used in the near term, to avoid the
    package support for it atrophying due to disuse, while not breaking the
    packages that have not yet implemented it.

    > 2) Enforce the target for all new uploads and change policy once we
    > exceed XX%.


    > The unstable/experimental buildds could be patched to call
    > 'build-arch' instead of build making any upload without
    > 'build-arch' FTBFS. The security buildds would be left
    > as is so nothing old breaks.


    Again, very impractical, particularly for transitions where binNMUs are
    involved.

    > 3) Require 'build-arch/indep' with Standards-Version x.y.z


    > Every source has a Standards-Version entry. dpkg-buildpackage could
    > call 'build-arch' if the standards version is new enough and fall
    > back to 'build' for older versions.


    That's an option, but doesn't even let us take advantage of build-arch
    support for existing packages that reference an older Standards-Version.

    Whatever happened to the idea of using make options to check for the
    existence of a target in debian/rules? IIRC we have a total of one package
    in the archive that stubbornly refuses to comply with Policy 4.9
    (debian/rules must be a makefile), so if we're entertaining solutions that
    make existing packages buggy, why would we not use the method that minimizes
    the number of packages that will be broken in the process?

    --
    Steve Langasek Give me a lever long enough and a Free OS
    Debian Developer to set it on, and I can move the world.
    vorlon@debian.org http://www.debian.org/


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Bug#229357: Can we require build-arch/indep targets for lenny?

    Hi,

    On Tue, 2007-06-26 at 14:33:26 +0100, Ian Jackson wrote:
    > Bill Allombert writes ("Re: Can we require build-arch/indep targets for lenny?"):
    > > At least, I would feel less alone.

    >
    > FWIW, I agree with you. I think the proposed `Build-Options' source
    > control field is a sensible addition and the bug should be implemented
    > immediately.
    >
    > Obviously the dpkg developers are rather busy at the moment. I think
    > that the right thing to do is to offer to NMU.


    Errr, what's the rush now to get this fixed? It's something that has
    been there like forever, the bug report proposes adding a new field
    which personally I don't like taking lightly.

    I've been pondering on what's the cleanest way to fix it for some time,
    and I tend to agree with Steve about using the make options to test
    for the existence of the targets. But as others have pointed out it's
    not clear why that change was reverted at the time.

    regards,
    guillem


    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: Bug#229357: Can we require build-arch/indep targets for lenny?

    On Fri, Jun 29, 2007 at 12:41:04AM +0300, Guillem Jover wrote:
    > > Obviously the dpkg developers are rather busy at the moment. I think
    > > that the right thing to do is to offer to NMU.

    >
    > Errr, what's the rush now to get this fixed? It's something that has
    > been there like forever, the bug report proposes adding a new field
    > which personally I don't like taking lightly.


    This field does not need to be exported to the Source file, so it does
    not have a large impact.

    > I've been pondering on what's the cleanest way to fix it for some time,
    > and I tend to agree with Steve about using the make options to test
    > for the existence of the targets. But as others have pointed out it's
    > not clear why that change was reverted at the time.


    One of the issue is that tools like sbuild and pbuilder which want to
    take advantage of the Build-Depends-Indep split needs to know whether
    dpkg-buildpackage will call debian/rules build or build-arch. So if you
    go that route, the exact criterium used by dpkg-buildpackage need to be
    published as an interface.

    Any additional detail is available at

    Cheers,
    --
    Bill.

    Imagine a large red swirl here.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: Bug#229357: Can we require build-arch/indep targets for lenny?

    In article <20070629211104.GC3320@yellowpig> (gmane.linux.debian.devel.general) you wrote:
    > On Fri, Jun 29, 2007 at 12:41:04AM +0300, Guillem Jover wrote:

    [...]
    >> I've been pondering on what's the cleanest way to fix it for some time,
    >> and I tend to agree with Steve about using the make options to test
    >> for the existence of the targets. But as others have pointed out it's
    >> not clear why that change was reverted at the time.


    http://bugs.debian.org/cgi-bin/bugre...t=0;bug=218893
    | -q checks for "up to dateness" ... the next time you ran the test, it
    | would fail because build-stamp had been touched and dpkg-buildpackage
    | would incorrectly run build for you instead.

    > One of the issue is that tools like sbuild and pbuilder which want to
    > take advantage of the Build-Depends-Indep split needs to know whether
    > dpkg-buildpackage will call debian/rules build or build-arch. So if you
    > go that route, the exact criterium used by dpkg-buildpackage need to be
    > published as an interface.


    I think that is just wrong. sbuild should not need to know anything
    about dpkg-buildpackage's internals and there is no need for change
    here. The currently used and proven interface is:

    1. install Build-Depends for running dpkg-buildpackage -B

    2. install Build-Depends *and* Build-Indep-Indep for running
    dpkg-buildpackage differently (e.g without any modifier or with -b)

    cu andreas
    --
    `What a good friend you are to him, Dr. Maturin. His other friends are
    so grateful to you.'
    `I sew his ears on from time to time, sure'


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. Bug#229357: Can we require build-arch/indep targets for lenny?

    On Sat, Jun 30, 2007 at 09:40:29AM +0200, Andreas Metzler wrote:
    > I think that is just wrong. sbuild should not need to know anything
    > about dpkg-buildpackage's internals and there is no need for change
    > here. The currently used and proven interface is:
    >
    > 1. install Build-Depends for running dpkg-buildpackage -B


    The issue we are trying to fix is that the current combination of
    Debian policy and dpkg-buildpackage actually require
    Build-Depends-Indep to be installed when running dpkg-buildpackage -B.

    Indeed dpkg-buildpackage -B calls 'debian/rules build' which
    requires Build-Depends-Indep to be installed. Since buildd actually
    implement 1) this cause packages to FTBFS until they are 'fixed' by
    having 'build' not depending on 'build-indep' (or equivalently, the
    build-indep task being performed directly by binary-indep), which is
    against the spirit of policy (because build-indep will then be
    executed under sudo or fakeroot).

    So this interface is used and proven to be wrong.

    > 2. install Build-Depends *and* Build-Indep-Indep for running
    > dpkg-buildpackage differently (e.g without any modifier or with -b)


    If you insist to go that road, you need to:

    1) Change policy to require build-arch is implemented anytime the field
    Build-Depends-Indep is provided.
    and
    2) Change dpkg-buildpackage -B to call build-arch if the field
    Build-Depends-Indep is present.

    Please submit patches if you are interested.

    However this proposal will cause a number packages to FTBFS until
    they are fixed (but less than always using build-arch).

    See for any additional details. I am
    merely restating the issues.

    Cheers,
    --
    Bill.

    Imagine a large red swirl here.


    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Bug#229357: Can we require build-arch/indep targets for lenny?

    Bill Allombert wrote:
    > On Sat, Jun 30, 2007 at 09:40:29AM +0200, Andreas Metzler wrote:
    >> I think that is just wrong. sbuild should not need to know anything
    >> about dpkg-buildpackage's internals and there is no need for change
    >> here. The currently used and proven interface is:


    >> 1. install Build-Depends for running dpkg-buildpackage -B


    > The issue we are trying to fix is that the current combination of
    > Debian policy and dpkg-buildpackage actually require
    > Build-Depends-Indep to be installed when running dpkg-buildpackage -B.


    Hello,
    Policy does not reflect current reality in that respect. The buildds
    do run dpkg-buildpackage -B and they do not install
    Build-Depends-Indep. Packages requiring Build-Depends-Indep for
    dpkg-buildpackage -B will FTBFS. Since that makes the package
    unreleasable there are not many packages around that work like that.
    (Except for source packages that do not build any arch-any packages
    and therefore are not autobuilt.)

    [snip]

    >> 2. install Build-Depends *and* Build-Indep-Indep for running
    >> dpkg-buildpackage differently (e.g without any modifier or with -b)


    > If you insist to go that road, you need to:


    > 1) Change policy to require build-arch is implemented anytime the field
    > Build-Depends-Indep is provided.
    > and
    > 2) Change dpkg-buildpackage -B to call build-arch if the field
    > Build-Depends-Indep is present.

    [...]

    No, that is not necessary. What needs to happen is just:
    ---------------
    Somehow make dpkg-buildpackage -B make use of the build-arch target
    if present. Either by detecting it automatically or by something like
    #229357.
    ---------------

    Once that happens the current wording in policy matches reality for
    packages proving a build-arch target.

    cu andreas
    --
    `What a good friend you are to him, Dr. Maturin. His other friends are
    so grateful to you.'
    `I sew his ears on from time to time, sure'


    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Bug#229357: Can we require build-arch/indep targets for lenny?

    Hi,

    Andreas Metzler wrote:

    > ---------------
    > Somehow make dpkg-buildpackage -B make use of the build-arch target
    > if present. Either by detecting it automatically or by something like
    > #229357.
    > ---------------


    The entire issue circles around not being able to reliably detect
    whether the target is present using a simple script. But who said it has
    to be a script?

    Proposed alternative solution:

    1. hack GNU make to support a "--has-target" option that returns an
    appropriate return code (hey, it's free software, after all!). Proposed
    return codes are 0 (yes), 1 (no) and 2 (error).

    2. make "dpkg-buildpackage -B" use this facility to determine whether
    the target is present. If yes, use the "build-arch" target to build; if
    no, use the "build" target after printing a warning.

    3. grep the build logs for warnings about missing "build-arch" target,
    add an entry to the TODO list on the package overview page on
    qa.debian.org and to DDPO.

    The only remaining question is what should happen with build failures in
    packages that provide a non-functional "build-arch" target. In my
    opinion, this is a genuine bug, even if policy can be read in a way that
    makes it disagree.

    Simon


    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Bug#229357: Can we require build-arch/indep targets for lenny?

    Simon Richter writes:

    > Hi,
    >
    > Andreas Metzler wrote:
    >
    >> ---------------
    >> Somehow make dpkg-buildpackage -B make use of the build-arch target
    >> if present. Either by detecting it automatically or by something like
    >> #229357.
    >> ---------------

    >
    > The entire issue circles around not being able to reliably detect
    > whether the target is present using a simple script. But who said it
    > has to be a script?
    >
    > Proposed alternative solution:
    >
    > 1. hack GNU make to support a "--has-target" option that returns an
    > appropriate return code (hey, it's free software, after
    > all!). Proposed return codes are 0 (yes), 1 (no) and 2 (error).
    >
    > 2. make "dpkg-buildpackage -B" use this facility to determine whether
    > the target is present. If yes, use the "build-arch" target to build;
    > if no, use the "build" target after printing a warning.
    >
    > 3. grep the build logs for warnings about missing "build-arch" target,
    > add an entry to the TODO list on the package overview page on
    > qa.debian.org and to DDPO.
    >
    > The only remaining question is what should happen with build failures
    > in packages that provide a non-functional "build-arch" target. In my
    > opinion, this is a genuine bug, even if policy can be read in a way
    > that makes it disagree.
    >
    > Simon
    >
    >
    > --
    > To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


    There are two points to this:

    1.) don't call build so build-indep is not called

    2.) have Build-Depends only contain packages needed for build-arch and
    binary-arch

    The seconds part requires that tools like sbuild and pbuilder know
    beforehand if build or build-arch will be used. Running debian-rules
    can always have side effects and can actively rely on them so a
    "--has-target" can not be implemented cleanly in make.

    So you missed the point.

    MfG
    Goswin


    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  11. Re: Can we require build-arch/indep targets for lenny?

    Steve Langasek writes:

    > On Mon, Jun 18, 2007 at 10:30:55AM +0200, Goswin von Brederlow wrote:
    >> I would like to gather up some momentum for a policy change. Namely
    >> that the build-arch/indep targets in debian/rules become required
    >> instead of being optional.

    >
    >> The reason for this is that dpkg-buildpackage can't reliable detect
    >> the existance of the build-arch/indep targets and must call 'build'
    >> instead. This forces every source to compile both architecture
    >> specific and architecture independent code on all buildds and
    >> increases the Build-Depends of packages a lot.

    >
    >> Current status:

    >
    >> I asked Lucas Nussbaum to rebuild all of debian with dpkg-buildpackage
    >> patched to call 'build-arch'. Here is the result:

    >
    >> 7326 packages rebuilt (all packages not Architecture:all)
    >> 1727 built successfully
    >> 5463 failed to build with a "no rule to make" error.
    >> 136 failed for other reasons (unsat builddeps, etc)

    >
    >> That means that only about 25% of debian package have a build-arch
    >> target. So there is still a long way to got.

    >
    >> Possible upgrade paths:

    >
    >> 1) Change policy now making 75% of package RC buggy instantly.

    >
    >> This sounds horrible but the fix is trivial and there is still a
    >> long time to lenny to fix it.

    >
    > No, the fix is not trivial; you will not get the buildd maintainers to
    > implement such a change when it makes 75% of the archive unbuildable, and
    > without such pressure you will never reach 100% adoption by package
    > maintainers.


    The fix IS trivial. You can't tell me that it is a problem to add
    "build-%: build" to your rules file when you are doing an upload
    anyway.

    Also by changing policy nothing becomes unbuildable as tools would not
    yet take advantage of that policy. It just means it would be a bug not
    to have the targets.

    > Any serious adoption path needs to get used in the near term, to avoid the
    > package support for it atrophying due to disuse, while not breaking the
    > packages that have not yet implemented it.
    >
    >> 2) Enforce the target for all new uploads and change policy once we
    >> exceed XX%.

    >
    >> The unstable/experimental buildds could be patched to call
    >> 'build-arch' instead of build making any upload without
    >> 'build-arch' FTBFS. The security buildds would be left
    >> as is so nothing old breaks.

    >
    > Again, very impractical, particularly for transitions where binNMUs are
    > involved.


    I give you that. binNMUs would be a slight problem. The idea predates
    binNMUs though so that was never discussed back then.

    >> 3) Require 'build-arch/indep' with Standards-Version x.y.z

    >
    >> Every source has a Standards-Version entry. dpkg-buildpackage could
    >> call 'build-arch' if the standards version is new enough and fall
    >> back to 'build' for older versions.

    >
    > That's an option, but doesn't even let us take advantage of build-arch
    > support for existing packages that reference an older Standards-Version.


    I don't consider that a big deal. We already don't take advantage of
    them now. If the majority of packages update to the new standrds
    version before lenny that is just fine.

    > Whatever happened to the idea of using make options to check for the
    > existence of a target in debian/rules? IIRC we have a total of one package
    > in the archive that stubbornly refuses to comply with Policy 4.9
    > (debian/rules must be a makefile), so if we're entertaining solutions that
    > make existing packages buggy, why would we not use the method that minimizes
    > the number of packages that will be broken in the process?


    Because detecting has side effects and is costly, if it wrks reliable
    at all. See other mails.

    MfG
    Goswin


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  12. Bug#229357: Can we require build-arch/indep targets for lenny?

    Hello,

    Goswin von Brederlow wrote:

    > The seconds part requires that tools like sbuild and pbuilder know
    > beforehand if build or build-arch will be used.


    For packages that do not implement build-arch, it is acceptable to call
    the build target with only B-D installed, because that is the way the
    autobuilders handle it now. So no problem there; packages that implement
    build-arch can move the dependencies not needed for building
    arch-dependent packages from B-D to B-D-I as soon as the autobuilders
    start using build-arch.

    Getting rid of unneeded build dependencies is mostly orthogonal to the
    issue at hand, though.

    > Running debian-rules
    > can always have side effects and can actively rely on them so a
    > "--has-target" can not be implemented cleanly in make.


    I am proposing hooking into the logic that ultimately decides that there
    is no such target in the Makefile and goes on to print "Don't know how
    to make 'foo'. Stop.". This means that Makefiles are rebuilt before that
    test is performed, we stop immediately before the point where we would
    go towards the first goal target.

    Yes, that means running commands that possibly have side effects. But we
    are going to run these commands anyway.

    Simon


    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  13. Bug#229357: Can we require build-arch/indep targets for lenny?

    On Sun, Jul 01, 2007 at 05:22:31PM +0200, Bill Allombert wrote:
    > On Sat, Jun 30, 2007 at 09:40:29AM +0200, Andreas Metzler wrote:
    > > I think that is just wrong. sbuild should not need to know anything
    > > about dpkg-buildpackage's internals and there is no need for change
    > > here. The currently used and proven interface is:


    > > 1. install Build-Depends for running dpkg-buildpackage -B


    > The issue we are trying to fix is that the current combination of
    > Debian policy and dpkg-buildpackage actually require
    > Build-Depends-Indep to be installed when running dpkg-buildpackage -B.


    > Indeed dpkg-buildpackage -B calls 'debian/rules build' which
    > requires Build-Depends-Indep to be installed. Since buildd actually
    > implement 1) this cause packages to FTBFS until they are 'fixed' by
    > having 'build' not depending on 'build-indep' (or equivalently, the
    > build-indep task being performed directly by binary-indep), which is
    > against the spirit of policy (because build-indep will then be
    > executed under sudo or fakeroot).


    > So this interface is used and proven to be wrong.


    Attached is a patch to dpkg which implements a check for a 'build-arch'
    target using 'make -f debian/rules -qn build-arch'.

    I looked into using make -pn, but Guillem Jover pointed out that this
    doesn't work if the 'build-arch' target is implemented using patterns.
    '-qn' appears the most reliable option; this is the same basic technique
    that was attempted once before and reverted by Adam Heath, the dpkg
    maintainer at the time, so I spoke with him about the reasons for the revert
    and it appears the concerns are mostly about dpkg behavior on systems that
    do not conform to Debian policy.

    I don't think that's a good enough reason to stall innovation that benefits
    Debian, but perhaps the current dpkg maintainers do; I'll try to lay out the
    technical details impartially for their consideration so they can make an
    informed decision.

    I believe the attached patch has the following characteristics:

    - Any packages in Debian that currently have existing but /broken/
    'build-arch' targets will fail to build because of the failure of this
    target.
    - Any packages that have a debian/rules which is not a valid Makefile will
    continue to build as before (the new code will conclude that there is no
    valid 'build-arch' target).
    - Packages in Debian that have a 'build-arch' target will have this target
    used instead of 'build' when 'dpkg-buildpackage -B' is called.
    - Packages in Debian that do not have a 'build-arch' target will continue to
    have their 'build' target called by 'dpkg-buildpackage -B'.
    - Behavior on systems where 'make' is not GNU make is undefined.
    Specifically, on such a system dpkg is likely to either conclude that
    /all/ packages support 'build-arch', or that /none/ of them support
    'build-arch', depending on whether and how 'make -qn' fails.

    This has the following further implications:

    - Barring any buggy 'build-arch' targets, all packages that currently build
    on Debian autobuilders should continue to build successfully and
    correctly.
    - Packages that do support 'build-arch' today will also build faster,
    because the indep build will now be skipped.
    - Packages that do not yet support 'build-arch' can adopt this target
    without any need for coordinated changes on the buildds.
    - Packages that include in their Build-Depends field build-dependencies
    which are only needed for the architecture-independent portion of the
    'build' target can move these build-dependencies to Build-Depends-Indep as
    soon as they have a 'binary-arch' target that does not depend on the
    'build' target, and a working 'build-arch' target that does not perform
    the related architecture-independent build operations. Packages that make
    this change to their Build-Depends field should also build-depend on the
    version of dpkg-dev introducing these semantics.

    Documenting this in policy should be straightforward if these changes to
    dpkg are accepted.

    Lucas has agreed to doing a full archive rebuild with a modified dpkg-dev,
    for comparison with the previous test. A dpkg-dev binary including this
    change can be found at
    .

    Cheers,
    --
    Steve Langasek Give me a lever long enough and a Free OS
    Debian Developer to set it on, and I can move the world.
    vorlon@debian.org http://www.debian.org/


  14. Re: Bug#229357: Can we require build-arch/indep targets for lenny?

    On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
    > I believe the attached patch has the following characteristics:
    > - Behavior on systems where 'make' is not GNU make is undefined.
    > Specifically, on such a system dpkg is likely to either conclude that
    > /all/ packages support 'build-arch', or that /none/ of them support
    > 'build-arch', depending on whether and how 'make -qn' fails.


    Too bad, both Solaris and BSD make fail the bad way, returning 1 on a bad
    target -- and neither has -v or --version. I haven't checked the rest, but
    it's likely they behave the same way.

    So, an idea: what about checking "make -f /dev/null blah 2>/dev/null" first,
    for some portability?

    --
    1KB // Microsoft corollary to Hanlon's razor:
    // Never attribute to stupidity what can be
    // adequately explained by malice.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  15. Re: Bug#229357: Can we require build-arch/indep targets for lenny?

    On Tue, Jul 03, 2007 at 09:54:03AM +0200, Adam Borowski wrote:
    > On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
    > > I believe the attached patch has the following characteristics:
    > > - Behavior on systems where 'make' is not GNU make is undefined.
    > > Specifically, on such a system dpkg is likely to either conclude that
    > > /all/ packages support 'build-arch', or that /none/ of them support
    > > 'build-arch', depending on whether and how 'make -qn' fails.


    > Too bad, both Solaris and BSD make fail the bad way, returning 1 on a bad
    > target -- and neither has -v or --version. I haven't checked the rest, but
    > it's likely they behave the same way.


    > So, an idea: what about checking "make -f /dev/null blah 2>/dev/null" first,
    > for some portability?


    What 'blah' are you planning to use that's guaranteed to not have broken
    side-effects in some cases on Debian packages?

    --
    Steve Langasek Give me a lever long enough and a Free OS
    Debian Developer to set it on, and I can move the world.
    vorlon@debian.org http://www.debian.org/


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  16. Bug#229357: Can we require build-arch/indep targets for lenny?

    Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep targets for lenny?"):
    > Attached is a patch to dpkg which implements a check for a 'build-arch'
    > target using 'make -f debian/rules -qn build-arch'.


    Why are we so resistant to the new debian/control field ? That
    doesn't require any of this messing about with make.

    Note that the current setup does not actually require debian/rules to
    be a makefile. I don't think we should introduce software which has a
    requirement if we can avoid it.

    Ian.


    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  17. Bug#229357: Can we require build-arch/indep targets for lenny?

    Simon Richter writes ("Re: Bug#229357: Can we require build-arch/indep targets for lenny?"):
    > The entire issue circles around not being able to reliably detect
    > whether the target is present using a simple script. But who said it has
    > to be a script?


    We want the package to _declare_ whether it supports this new target.

    The proposed -Options field will actually be very useful for any
    other enhancements we make to the source package format.

    > Proposed alternative solution:
    >
    > 1. hack GNU make to support a "--has-target" option that returns an
    > appropriate return code (hey, it's free software, after all!). Proposed
    > return codes are 0 (yes), 1 (no) and 2 (error).


    OMG WTF BBQ

    (ie, this is a terrible suggestion)

    Ian.


    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  18. Re: Bug#229357: Can we require build-arch/indep targets for lenny?

    Ian Jackson writes:
    > Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep targets for lenny?"):
    >> Attached is a patch to dpkg which implements a check for a 'build-arch'
    >> target using 'make -f debian/rules -qn build-arch'.


    > Why are we so resistant to the new debian/control field ? That
    > doesn't require any of this messing about with make.


    Agreed. If I had my way, we'd add a Homepage debian/control field as
    well; instead we have an ugly workaround hack due to similar resistance.

    I think the addition of a new control field is a nicely elegant solution
    to the problem and is something we can use later on.

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  19. Bug#229357: Can we require build-arch/indep targets for lenny?

    On Tue, Jul 03, 2007 at 06:07:54PM +0100, Ian Jackson wrote:
    > Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep targets for lenny?"):
    > > Attached is a patch to dpkg which implements a check for a 'build-arch'
    > > target using 'make -f debian/rules -qn build-arch'.


    > Why are we so resistant to the new debian/control field ? That
    > doesn't require any of this messing about with make.


    But it does require the maintainer to keep three bits of information in
    sync: the new declarative Build-Options field, the build-arch target, and
    the Build-Depends field. That's added complexity which means an added
    opportunity for bugs, so if the complexity can be avoided I think it's
    worthwhile.

    If the dpkg maintainers feel that this autodetection isn't adequate, I do
    support implementing build-arch by way of Build-Options. The benefits would
    be realized more slowly, but they would be realized, and without the
    insanity of making 75% of our packages FTBFS in unstable first.

    > Note that the current setup does not actually require debian/rules to
    > be a makefile. I don't think we should introduce software which has a
    > requirement if we can avoid it.


    This doesn't require debian/rules to be a makefile either (though Policy
    does), it just requires that debian/rules be a makefile *if* the package
    implements build-arch and uses the corresponding semantics for
    Build-Depends.

    Anyway, for the perverse, the following is a valid makefile and a valid
    shell script.

    #!/bin/sh

    fakeout="
    build-arch: "

    case "$1" in
    build-arch)
    echo whee fun.
    ;;
    esac



    --
    Steve Langasek Give me a lever long enough and a Free OS
    Debian Developer to set it on, and I can move the world.
    vorlon@debian.org http://www.debian.org/


    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  20. Re: Bug#229357: Can we require build-arch/indep targets for lenny?

    On Tue, Jul 03, 2007 at 10:54:07AM -0700, Russ Allbery wrote:
    > Ian Jackson writes:
    > > Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep targets for lenny?"):
    > >> Attached is a patch to dpkg which implements a check for a 'build-arch'
    > >> target using 'make -f debian/rules -qn build-arch'.


    > > Why are we so resistant to the new debian/control field ? That
    > > doesn't require any of this messing about with make.


    > Agreed. If I had my way, we'd add a Homepage debian/control field as
    > well; instead we have an ugly workaround hack due to similar resistance.


    Heh, I was very much in favor of Homepage as a debian/control field; my
    objections to this use of Build-Options is not to the addition of this field
    (which also has other benefits), but to this particular use of it to declare
    information that must also be represented elsewhere in the package.

    --
    Steve Langasek Give me a lever long enough and a Free OS
    Debian Developer to set it on, and I can move the world.
    vorlon@debian.org http://www.debian.org/


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast