Debian Bug report logs - #10091
dpkg-buildpackage order of operations

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Brian White <bcwhite@verisim.com>

To: Debian Bugs <submit@bugs.debian.org>

Subject: dpkg-buildpackage order of operations

Date: Sat, 24 May 1997 12:42:46 -0400

Package: dpkg-dev
Version: 1.4.0.8

This isn't a bug...  just an idea.

Would it be possible to change "dpkg-buildpackage" such that it makes the
binary packages before the source packages?  This has two advantages I
can see:

1)  Since the maintainer has probably just finished building a binary
package and has been testing installing it, there is likely nothing to
be done for the "build" step and thus the "buildpackage" command would
take far less time.

2)  Making the source package last means that all derived files are
automaticially cleaned out and not left around.  Since "buildpackage" is
likely the very last step in the process, those derived files are
probably not going to be used for a while anyway and won't end up
forgotten about and taking up large amounts of disk space.

                                          Brian
                                 ( bcwhite@verisim.com )

-------------------------------------------------------------------------------
       Touch passion when it comes your way.  It's rare enough as it is;
       don't walk away when it calls you by name.  -- Marcus (Babylon 5)

Message #10 received at 10091@bugs.debian.org (full text, mbox, reply):

From: Klee Dienes <klee@mit.edu>

To: Brian White <bcwhite@verisim.com>

Cc: 10091@bugs.debian.org

Subject: Re: Bug#10091: dpkg-buildpackage order of operations

Date: 24 May 1997 16:13:52 -0400

One advantage to the current system is that it ensures that the system
can be built from scratch after a 'make clean'.  Especially when
porting packages for the first time, I sometimes tend to 'cheat', and
build a few of the object files by hand.  Having the 'make clean' step
makes sure that 'cheating' like this gets caught before the package is
released.

On the whole, though, I agree that the advantages to the change
outweigh the disadvantages.  Would anyone with strong opinions about
this change E-mail me privately with their reasons?  I'll summarize to
the list in a couple of days and make the change if there are no
overwhelming objections.

Message #15 received at 10091@bugs.debian.org (full text, mbox, reply):

From: Christian Schwarz <schwarz@monet.m.isar.de>

To: Klee Dienes <klee@mit.edu>, 10091@bugs.debian.org

Subject: Re: Bug#10091: dpkg-buildpackage order of operations

Date: Sun, 25 May 1997 12:17:12 +0200 (CEST)

On 24 May 1997, Klee Dienes wrote:

> One advantage to the current system is that it ensures that the system
> can be built from scratch after a 'make clean'.  Especially when
> porting packages for the first time, I sometimes tend to 'cheat', and
> build a few of the object files by hand.  Having the 'make clean' step
> makes sure that 'cheating' like this gets caught before the package is
> released.
> 
> On the whole, though, I agree that the advantages to the change
> outweigh the disadvantages.

*WHAT* ?!?!? (sorry for shouting :)

No, I strongly object here. We already have problems that some of our
source packages can't be compiled straight of the box (for example, if
people create new directories that are not included in the .orig.tar.gz)
so I would not like to make such things even more easy!

However, I can understand Brian with his request since I had the same
problem. (My mysql package needs about 20 minutes to compile from scratch
on my P120. This surely can be reduced with such a method.)

Therefore, I suggest to have two different "modes" for dpkg-buildpackage:
a test-build mode and a production-mode. The first will only create the
.deb, without running "debian/rules clean" at all and without creating a
source package and a diff, while the latter mode will behave just what we
have now. Thus, the developer can test his package very easily but we
don't loose the consistency of our source packages.

Note that the developer will have to test the "production .deb" too, since
this might be different from the "test-build .deb", if he cheated
somewhere.


Please email me again, if you are still thinking of changing this
behaviour of dpkg-buildpackage ;-)


Thanks,

Chris

--                  Christian Schwarz
                   schwarz@monet.m.isar.de, schwarz@schwarz-online.com
                  schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
                       
                PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
              
 CS Software goes online! Visit our new home page at
 	                                     http://www.schwarz-online.com

Message #20 received at 10091@bugs.debian.org (full text, mbox, reply):

From: Klee Dienes <klee@mit.edu>

To: Christian Schwarz <schwarz@monet.m.isar.de>, 10091@bugs.debian.org

Subject: Re: Bug#10091: dpkg-buildpackage order of operations

Date: Sun, 25 May 1997 10:52:16 -0400

Wow, that certainly seems to have gotten people's attention.  My
thanks to Christian as well as to the several people who E-mailed me
privately.  I'm glad to see so many people have strong feelings about
verifying the ability to build packages completely and easily from
source.

Given the number of strong objections to the change, and given that I
suspect a better solution will drop out of the source package changes
I'm working on (I'll be posting on that soon; sorry for the delay),
I'll defer this issue for a couple of weeks.

[ A note on the source package changes: recently I've seen some
messages proposing that we hold off on tasks like upgrading the
old-format source packages until the source package changes are
completed.  Please be reassured that I have no intention of changing
the source package format in a way that is not fully
backwards-compatible.  Converting old-format packages to the new
format will in fact help the effort significantly, as it will allow us
to better test the automatic distribution-building capabilities
proposed for the new tools. ]

Message #25 received at 10091@bugs.debian.org (full text, mbox, reply):

From: Brian White <bcwhite@verisim.com>

To: Christian Schwarz <schwarz@monet.m.isar.de>, 10091@bugs.debian.org

Subject: Re: Bug#10091: dpkg-buildpackage order of operations

Date: Mon, 26 May 1997 13:50:30 -0400

> No, I strongly object here. We already have problems that some of our
> source packages can't be compiled straight of the box (for example, if
> people create new directories that are not included in the .orig.tar.gz)
> so I would not like to make such things even more easy!

I can understand this, but since almost everybody (if not everybody) will
build packages by doing "debian/rules build; debian/rules binary", why
will this cause any additional problems?


> Therefore, I suggest to have two different "modes" for dpkg-buildpackage:
> a test-build mode and a production-mode. The first will only create the
> .deb, without running "debian/rules clean" at all and without creating a
> source package and a diff, while the latter mode will behave just what we
> have now. Thus, the developer can test his package very easily but we
> don't loose the consistency of our source packages.

How is this new mode different from just doing "debian/rules binary"?

                                          Brian
                                 ( bcwhite@verisim.com )

-------------------------------------------------------------------------------
Debian GNU/Linux!  Search it at  http://insite.verisim.com/search/debian/simple

Message #30 received at 10091@bugs.debian.org (full text, mbox, reply):

From: Christian Schwarz <schwarz@monet.m.isar.de>

To: Brian White <bcwhite@verisim.com>

Cc: 10091@bugs.debian.org

Subject: Re: Bug#10091: dpkg-buildpackage order of operations

Date: Mon, 26 May 1997 20:25:16 +0200 (CEST)

On Mon, 26 May 1997, Brian White wrote:

> > No, I strongly object here. We already have problems that some of our
> > source packages can't be compiled straight of the box (for example, if
> > people create new directories that are not included in the .orig.tar.gz)
> > so I would not like to make such things even more easy!
> 
> I can understand this, but since almost everybody (if not everybody) will
> build packages by doing "debian/rules build; debian/rules binary", why
> will this cause any additional problems?

Are you sure people use this method? We really should write more
documentation :-) In the past I used `dpkg-buildpackage -rsudo' which does
all necessary things for the upload, for example PGP signing etc. 

But now I use Christoph's "build" program. I just run "sudo build" and
everything is fine.

But you are right, for testing purposes "debian/rules build; debian/rules
binary" is enough. (I just realized that I built a very complicated shell
script from the dpkg-buildpackage sources just to run these two commands
;-)


Cheers,

Chris

--                  Christian Schwarz
                     schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian is looking     schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
for a logo! Have a
look at our drafts     PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
at    http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/

Message #35 received at 10091@bugs.debian.org (full text, mbox, reply):

From: "Christian Hudon" <chudon@ee.mcgill.ca>

To: Christian Schwarz <schwarz@monet.m.isar.de>, 10091@bugs.debian.org

Cc: Brian White <bcwhite@verisim.com>

Subject: Re: Bug#10091: dpkg-buildpackage order of operations

Date: Mon, 26 May 1997 16:27:38 +0000

[Message part 1 (text/plain, inline)]

On May 26, Christian Schwarz wrote
> 
> But you are right, for testing purposes "debian/rules build; debian/rules
> binary" is enough. (I just realized that I built a very complicated shell
> script from the dpkg-buildpackage sources just to run these two commands
> ;-)

Make that "debian/rules binary". I don't know about your Debian packages,
but in all of mine, the 'binary' target depends on the 'build' target. And
I think that's what the Debian Programmer/Policy Manual mandates too.

  Christian

[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.