[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages



control: subscribe -1


>>>>> "Charles" == Charles Plessy <plessy@debian.org> writes:


    Charles> The 3.0 (native) format is useful when packaging a work
    Charles> that is developped and distributed in a Git repository.
    Charles> Please leave us this possibility.

Let me describe the use case I have which is an expansion on the above.
I have a bunch of software that I perform daily builds for  out of
version control (git in my case but the issue applies to other vcs as
well).
The software does have upstream versions but is not stable enough that
upstream release tarballs are useful to anyone.
Honestly at this point, I'm not sure anyone will ever find upstream
tarballs useful; anyone who is likely to want to build this from source
probably has a copy of git and can checkout a tag.

There is a packaging branch and an upstream branch.
Changes made on the packaging branch increment the debian revision;
changes made on the  ustream branch eventually involve an increment to
the upstream version.

Things get dumped into a Debian reprepro repository, and into Ubuntu
PPAs.
Eventually, things will get stable enough that I'll upload to a PPA.

Prior to that, I need a way to build a Debian package including source
from a directory without an upstream tar ball.  3.0(git) is not a
reasonable option because archive management programs have very little
support for it, and because package download tools probably aren't well
tested with it.

I'm happy to entertain other options rather than 3.0(native) but my
requirements are:

* support for upstream version
* support for debian revision

* No need to have upstream sources available to dpkg-buildpackage prior
  to running it

* No need to maintain .orig.tar.gz artifacts  produced by dpkg-source
  and keep the checksums of these artifacts consistent between packages
  with the same upstream versions.


Reply to: