Need a way to use an .orig.tar.gz for some packages

[Robert Collins]

Some packages are large with few changes each day. In those cases using a
.orig.tar.gz is worth it, so being able to support that would be good.

[James Westby (james-w)]

bzr-builder currently builds native packages exactly to sidestep these
issues. Are you not seeing native packages being built?

Thanks,

James

[Robert Collins (lifeless)]

On Fri, 2009-10-23 at 09:20 +0000, James Westby wrote:
> bzr-builder currently builds native packages exactly to sidestep these
> issues. Are you not seeing native packages being built?

Oh, no. I was misdiagnosing the bug with email (as soyuz wasn't giving
feedback; allowing normal packages would be nice though - is there an
option for that? [consider e.g. openoffice]).

-Rob

[James Westby (james-w)]

There isn't an option yet.

It doesn't make much sense for a lot of packages, but the daily changes
as a proportion of the overall size will be very small for some packages as
you indicate.

I would like to implement it, but it's not easy. How do you specify where
to get the tarball from and such?

Thanks,

James

[Robert Collins (lifeless)]

On Fri, 2009-10-23 at 10:52 +0000, James Westby wrote:
> There isn't an option yet.
>
> It doesn't make much sense for a lot of packages, but the daily changes
> as a proportion of the overall size will be very small for some packages as
> you indicate.
>
> I would like to implement it, but it's not easy. How do you specify where
> to get the tarball from and such?

Doesn't bzr-builddeb do this already? :)

-Rob

[James Westby (james-w)]

On Fri Oct 23 23:39:50 UTC 2009 Robert Collins wrote:
> On Fri, 2009-10-23 at 10:52 +0000, James Westby wrote:
> > There isn't an option yet.
> >
> > It doesn't make much sense for a lot of packages, but the daily changes
> > as a proportion of the overall size will be very small for some packages as
> > you indicate.
> >
> > I would like to implement it, but it's not easy. How do you specify where
> > to get the tarball from and such?
>
> Doesn't bzr-builddeb do this already? :)

bzr-builddeb isn't used. They are incompatible currently, at the least because
of lack of nested tree support.

Thanks,

James

[Robert Collins (lifeless)]

On Sat, 2009-10-24 at 00:09 +0000, James Westby wrote:

> bzr-builddeb isn't used. They are incompatible currently, at the least because
> of lack of nested tree support.

I'm not sure how nested trees are involved; as bzr doesn't support them
it seems like neither -builder or -builddeb can be using them....

And I realise -builder doesn't use -builddeb, I was meaning that the
same solution can/should apply.

Certainly for the things I'm doing I'll be merging normal packaging
branches in the recipe, so all the builddeb metadata should be present.

-Rob

[James Westby (james-w)]

On Sat Oct 24 00:23:17 UTC 2009 Robert Collins wrote:
> On Sat, 2009-10-24 at 00:09 +0000, James Westby wrote:
> > bzr-builddeb isn't used. They are incompatible currently, at the least because
> > of lack of nested tree support.
>
> I'm not sure how nested trees are involved; as bzr doesn't support them
> it seems like neither -builder or -builddeb can be using them....

bzr-builder can be used to create "nested trees", but obviously can't
represent them in bzr, so bzr-builddeb can't pick them up and use them.
It's just one branch inside another. It could be extended to allow
these things to be specified, but as nested trees were moving forwards
waiting for that seemed like the better idea.

> And I realise -builder doesn't use -builddeb, I was meaning that the
> same solution can/should apply.

To some extent, yes.

> Certainly for the things I'm doing I'll be merging normal packaging
> branches in the recipe, so all the builddeb metadata should be present.

Yes.

Thanks,

James

[Robert Collins (lifeless)]

On Sat, 2009-10-24 at 10:30 +0000, James Westby wrote:
>
> bzr-builder can be used to create "nested trees", but obviously can't
> represent them in bzr, so bzr-builddeb can't pick them up and use
> them.
> It's just one branch inside another. It could be extended to allow
> these things to be specified, but as nested trees were moving forwards
> waiting for that seemed like the better idea.

As an aside, config-manager is ~ bzr-builder, but without the debian
aspects or the merge command.

Anyhow, I don't think its a good idea to limit bzr-builder to the
least-functional subset of its capabilities - if no nest rules are used,
why not permit e.g. recording the result, pushing to a branch, doing an
incremental build etc.

-Rob

[Benjamin Drung (bdrung)]

I would like to see orig.tar.gz building support. What do you think about changing the recipe format to something like that:

# bzr-builder format 0.3
lp:bzr
merge fix-build lp:~bzr/bzr/fix-build
tarball 1.0+{time}
merge packaging lp:~bzr/bzr/packaging
build 1.0+{time}-0ubuntu1

There will be a new command "tarball", which creates the orig.tar.gz, the parameter is the version. The build command will be at the end and will create the debian package. The version is there as parameter. This format would help to split the recipe part from the Debian packaging part.

[Benjamin Drung (bdrung)]

BTW, what happens to a package that uses 3.0 (quilt) as source format? Then dpkg-source will fail without a source tarball.

[James Westby (james-w)]

> BTW, what happens to a package that uses 3.0 (quilt) as source format?
> Then dpkg-source will fail without a source tarball.

Yes, I think you are right about that. That's tricky to workaround without fixing
this bug.

> I would like to see orig.tar.gz building support. What do you think about changing
> the recipe format to something like that:

> # bzr-builder format 0.3
> lp:bzr
> merge fix-build lp:~bzr/bzr/fix-build tarball 1.0+{time}
> merge packaging lp:~bzr/bzr/packaging build 1.0+{time}-0ubuntu1

> There will be a new command "tarball", which creates the orig.tar.gz, the parameter
> is the version. The build command will be at the end and will create the debian package.
> The version is there as parameter. This format would help to split the recipe part from
> the Debian packaging part.

I would prefer it to be more automatic than that, and make use of the same functionality
as bzr-builddeb.

Something like this should work:

  1. Find the final version number that will be used.
  2. Take the upstream part of this.
  3. Look for a tag in the same way as bzr-builddeb. If it exists:
      - Use pristine-tar to provide the tarball
     If it doesn't:
      - Build a native package.
  4. This would mean that you had to use merge-upstream from bzr-builddeb at some point
      as well as changing the version number in the recipe. With Rob's {debupstream} expansion
      this would be automatic if you are managing the packaging branch with bzr-builddeb.

Thanks,

James

[Benjamin Drung (bdrung)]

This will not help in my use case. I am building daily packages for audacity. Therefore the upstream tarball will change with every new upload.