[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