On Thu, Sep 26, 2019 at 05:14:59PM +0200, Fabio Valentini wrote:
On Thu, Sep 26, 2019 at 4:57 PM Jeremy Cline
<jeremy(a)jcline.org> wrote:
>
> On Thu, Sep 26, 2019 at 04:49:31PM +0200, Fabio Valentini wrote:
> > On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
> > <zbyszek(a)in.waw.pl> wrote:
> > >
> > > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > > > Instead I prefer a clone of the master upstream git repo and maintain
a
> > > > branch with patches cherry-picked into it. This is used to
auto-generate
> > > > patches for the Fedora RPM, at the same time updating the patch file
list
> > > > in the RPM spec. The only manual step is adding the changelog entry
&
> > > > bumping release number.
> > >
> > > Quick note: this is essentially what debian does.
> >
> > Ugh. Can we please just agree that source-git (vs. dist-git) is almost
> > always a bad idea?
> >
>
> Can you expand on that? To me it is a much easier way to maintain
> packages, but I don't have tons of experience doing that and I'm
> perhaps not the "average package maintainer". Hearing other perspectives
> would be helpful.
Sorry, I should have expanded on that short statement.
I literally maintain hundreds of packages, mostly by myself (yes,
that's too many, but that's a problem that tooling can't fix).
I'd hazard to guess that 90% of these packages don't contain *any*
patches on top of an upstream release. So pointing the .spec file to
an upstream tarball is the *absolute easiest thing* possible, and I
don't want to have to deal with the upstream git repo contents for
these packages at all.
For another 9% of packages, I maintain a small set of local patches
(up to two patches or so), which I can "generate on the fly" for every
new upstream release (if necessary), and which is only a small amount
of work.
For the remaining 1% (about 2-3 of my packages), I maintain a local
git repository with branches for every release, where I maintain a
small downstream patch-set. This seems to correspond to a source-git
approach, and might be similar to what you're doing.
So, to summarize: I just don't want the absolute edge case to become
the general case. It would make things *massively* more complicated
for me, and I guess that applies to the "average packager" in fedora,
as well.
Ah right, that makes a lot of sense.
I can imagine automatically detecting the new upstream release, building
that, and presenting the packager with a easy-to-review PR that you just
click "merge" on instead of pointing the specfile at a new tarball.
Some of these could (I think) be solved with quality tooling, but I
don't see that kind of stuff appearing any time soon. I do think all
these things would have to be addressed, though, and I definitely agree
that the corner cases shouldn't drive the workflow.
- Jeremy