Is %autosetup another unwanted baby of Fedora?
ngompa at fedoraproject.org
Tue Jul 14 08:51:23 UTC 2015
On Tue, Jul 14, 2015 at 4:24 AM, Mikolaj Izdebski <mizdebsk at redhat.com>
> On 07/13/2015 02:39 PM, Marcin Juszkiewicz wrote:
> > When I moved to Fedora after years of doing Debian packages I noticed
> > that there is no such thing as patch management when it comes to Fedora
> > packages. Everyone is using %patch macro with files of random patchlevel
> > (some even use reverse patches).
> > %autosetup was created to handle that but probably less than 5% of
> > packages use it. Why?
> > Is it because no one told that it exists? Or maybe because
> > implementation has some issues which no one wants to fix? Or other (I
> > exclude laziness of package maintainers)?
> I also like how Debian patches their packages (stardardization: quilt,
> DEP-3, patch tracker web app, ...) and I was initially quite eager about
> %autosetup/%autopatch, but it turned out to be unusable for me.
> I maintain most of patches as commits in private branches of upstream
> git repos and generate them with "git format-patch
> <latest-release-tag>". %autosetup and %autopatch don't work with patches
> generated this way, while %patch does.
> Another (lesser) reason is increased difficulty of backporting spec
> files to work with older rpm-build, such as when creating software
> collections for older OS.
> I use %autopatch in one of my packages (eclipse-m2e-core) so that I
> don't forget how it works (or doesn't work :)
> Mikolaj Izdebski
> Software Engineer, Red Hat
> IRC: mizdebsk
> devel mailing list
> devel at lists.fedoraproject.org
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
I know that I personally cheat a bit with one of my internal packages and
just use git to apply patches. That said, I literally found out about
%autosetup and %autopatch yesterday morning from a conversation with
Marcin in IRC.
I have to wonder if we have a fundamentally bigger problem: our
documentation for packaging and the capabilities of RPM is scattered and
As much as I personally don't like how the Debian packaging format works, I
didn't find it very difficult to find up to date information on it.
maintainers' guide <https://www.debian.org/doc/manuals/maint-guide/> is
updated fairly regularly (it was just updated last month!), whereas we
don't even have one (well, we've got scattered documents about package
reviews <https://fedoraproject.org/wiki/Package_Review_Process>, which
links to how to use the Fedora infrastructure, but doesn't even mention how
to use mock, our local build tool, to verify our packages are sound. Our
has been sitting in drafts forever, and was last updated in the Fedora 18
cycle. That was back in early 2013! With weak dependencies and other
changes to RPM since then, it needs some love.
And of course, the RPM Guide
hasn't been updated in almost five years! Heck, it doesn't even mention
DNF, and it mentions AutoRPM (which has been dead and gone for several
years now), up2date, and several other tools that aren't used anymore.
SUSE's older rug and newer (and admittedly very nice) ZYpper isn't
As a project, we appear to suck at keeping our documentation sane when it
comes to stuff like this. Now, don't get me wrong, we've done a fantastic
job documenting everything else, including all the new stuff that gets
introduced into the world through Fedora (firewalld, NetworkManager's
server mode CLI, etc.). But arguably the most important documentation
that's central to RHEL, Fedora, and indeed the RPM world has not seen much
love, if any at all.
And of course, I'm not saying that it's easy to do this. But I think when
someone like Marcin mentions a nice feature that I've never even heard of
that would have made my life easier for some of my packages, I just feel
rotten inside because I had to something hackish or whatnot to get the job
done. And I personally don't like doing that. I want my packages to be
clean and excellent examples of how to make packages well.
Another example of a feature that I didn't even know about until I dug into
example spec files all over the place was how to do conditional logic that
triggered based on definition switches passed from rpmbuild. It's somewhat
vaguely documented elsewhere on the internet
but not well documented where it matters.
Frankly, I think this is pretty depressing for us, because we're trying to
make it easier for people to learn our system and use it well. And things
like horribly written packages come out of inadequate documentation and
lack of mentorship. The latter is a people problem that's difficult to
solve, but the former is much more easily solved once we actually know
*what* RPM can do and how to illustrate it.
Neal Gompa (FAS: ngompa)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel