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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
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 unloved.
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. Their package maintainers' 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, 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 packaging guide 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 mentioned either.
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)
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
