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

[Dmitry Smirnov]

On Tuesday 15 September 2015 11:28:01 Martín Ferrari wrote:
> 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.

What is the problem with minor inconsistency if there is no difference in how 
package is built? It is the same git repository and most of actions will be 
the same (unlike SVN repositories for example). Besides merging upstream 
sources is separate effort that have little to do with packaging. If we want 
learning curve to be less steep we need to avoid require maintainer to be 
profoundly experienced with git. I still remember my frustration when I got 
my first merge error on importing upstream tarball and hours I wasted in 
order to resolve the problem instead of doing meaningful work on package.

What do we achieve by having upstream sources in "master"?

Besides we are all have our preferences and I do not wish to impose mine on 
others. There is such thing as Maintainer's comfort and convenience -- I 
believe it matters more than minor inconsistency. We already have those 
inconsistencies -- like you've said some packages need two upstream branches 
and some don't. I'd argue that when `uscan` works one needs no "upstream" 
branch at all but of course there is no harm to have local upstream branch or 
to push DFSG-compliant upstream branch (if it is not too heavy) to shared 
repository. It should be decided on case-to-case basis by maintainers.

I want to mention KDE team again -- they have to work with non-DFSG packages 
with over 20_000 files (e.g. Calligra) and it is such a hassle to import 
upstream sources that they've decided to make it a team's policy to track 
only packaging. As result their repositories are very small.

Once again, I believe we should allow small variations in repository layout 
for best maintainer's convenience.


> 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.

I think it is a labour intensive, and requires you to track non-DFSG changes 
as well as repackaged ones. I do not want to have non-DFSG stuff in 
repositories at all. Also to avoid bloating public repository I do not want 
to store upstream history -- not everyone needs upstream branch unless of 
course there are no formal upstream releases...

-- 
All the best,
 Dmitry Smirnov.

---

Few people are capable of expressing with equanimity opinions which
differ from the prejudices of their social environment. Most people are
even incapable of forming such opinion.
        -- Albert Einstein, from "Aphorisms for Leo Baeck;
           Opinions of Albert Einstein"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20150915/19e6709b/attachment-0001.sig>