[pkg-go] Various problems with packages in the group

Martín Ferrari tincho at tincho.org
Tue Sep 15 08:28:01 UTC 2015


Hi,

On 14/09/15 12:25, Dmitry Smirnov wrote:

> My solution to that supper-annoying problem is to keep Debian packaging (i.e. 
> "debian/*" files) and upstream files apart, unmerged. Therefore "master" 
> branch will contain only debian packaging and "upstream" branch holds 
> upstream changes. Simply add the following to your "debian/gbp.conf" file:

The problem with this (apart that I find it much more annoying not to
have the source), is inconsistency. I think the team should either keep
all the sources or none. Otherwise, one has to deal with N different
packaging workflows, and that does not scale.

Let's decide on one way of doing this, and have all the packages follow it.

>> On the other hand, not having the upstream source at all (I found one
>> package like that today) is bothersome, and I don't see any good reason
>> for that..

> In Debian packaging perhaps the most annoying, needless and time-consuming 
> thing for me is "gbp import-orig" procedure especially for packages where 
> DFSG-repacking of orig.tar is necessary. DFSG clean-up of a new package is a 
> continuous process hence I usually refrain from importing orig.tar until it 
> is ready. Otherwise there will be versions like +dfsg19 and a lot of time 
> will be wasted...
> 
> I understand that when upstream is not producing formal releases we need 
> "upstream" branch to generate orig.tar but only because `uscan` can not 
> generate orig.tar from checkout.

For repackaging, what I do instead is to keep an upstream branch that
follows upstream git history, and from there create a 'repackaged'
branch that has all the needed removals. It has some work when merging
in an extra version, but in general it is pretty straightforward and
keeps a record of how the source was changed.

-- 
Martín Ferrari (Tincho)



More information about the Pkg-go-maintainers mailing list