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

Re: Bug#719624: Upgrading xrdp

Hi Mike,

On Tue, Apr 19, 2016 at 10:17:07AM +0000, Mike Gabriel wrote:
> Personally, I am not a great fan of gbp. It has caused me more trouble than
> served any good (and I really think that gbp is a great tool for Debian
> packaging, as I said, my personal workflow does not use it).
> What I prefer doing (and this is personal style, really):
>   o Have a well-defined tarball (i.e. provided by upstream, Debian archive
> (snapshot.debian.org), pristine-tar)
>   o Have a Git repo with debian/ folder only.
> Then I do:
>   o Obtain the tarball (get-orig-source, pristine-tar checkout, etc.)
>   o then:
>       $ debuild -uc -us -S -Zxz (on the folder with the debian/ folder only
> in it)
>       $ cd ..
>       $ sbuild -sAd unstable <dsc-file>
> That works perfectly for all of my packages (MATE desktop, GOsa).

So you are using the workflow I use with SVN. :-)
> I once dropped using gbp when I discovered that gbp does not support
> multi-tarball Debian packages (GOsa packaging is unhandable with gbp). This
> may have changed meanwhile, but I don't see that benefit of shipping
> upstream code in packaging repos. (Maybe I have looked to much at
> http://pkgs.fedoraproject.org/cgit/rpms/, as well).

I can confirm that the benefit of having upstream code is limited - for
your workflow its probably not needed.
> About the tarball download source: Once some upstream release has been
> uploaded to Debian with source format 3.0, I consider the upstream tarball
> being available in Debian (or on snapshots.debian.org). Personally, I don't
> see the extra gain of shipping the same code in Git. Again, very personal
> style and way of seeing things.

I have no idea how many packages I touched in Debian Med team Git but
its possibly more than 100.  Our team policy was developed by several
people all confident that gbp is a great tool and I adapted to this
workflow with some stumbling stones in the beginning.  My summary is: I
have the least problems with this compared to all other workflows I
adapted to.  Thus I convert any package with tarballs diverging from an
upstream download tarball to this repository layout.  Since I personally
do not see any disadvantage for your workflow (despite the fact that
some extra diskspace might be consumed) I would be really happy if we
could agree upon this for xrdp.
Kind regards



Reply to: