<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif;font-size:large"><span style="font-family:arial,sans-serif;font-size:small">On Tue, Jul 14, 2015 at 4:24 AM, Mikolaj Izdebski </span><span dir="ltr" style="font-family:arial,sans-serif;font-size:small"><<a href="mailto:mizdebsk@redhat.com" target="_blank">mizdebsk@redhat.com</a>></span><span style="font-family:arial,sans-serif;font-size:small"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/13/2015 02:39 PM, Marcin Juszkiewicz wrote:<br>
> When I moved to Fedora after years of doing Debian packages I noticed<br>
> that there is no such thing as patch management when it comes to Fedora<br>
> packages. Everyone is using %patch macro with files of random patchlevel<br>
> (some even use reverse patches).<br>
><br>
> %autosetup was created to handle that but probably less than 5% of<br>
> packages use it. Why?<br>
><br>
> Is it because no one told that it exists? Or maybe because<br>
> implementation has some issues which no one wants to fix? Or other (I<br>
> exclude laziness of package maintainers)?<br>
<br>
</span>I also like how Debian patches their packages (stardardization: quilt,<br>
DEP-3, patch tracker web app, ...) and I was initially quite eager about<br>
%autosetup/%autopatch, but it turned out to be unusable for me.<br>
<br>
I maintain most of patches as commits in private branches of upstream<br>
git repos and generate them with "git format-patch<br>
<latest-release-tag>". %autosetup and %autopatch don't work with patches<br>
generated this way, while %patch does.<br>
<br>
Another (lesser) reason is increased difficulty of backporting spec<br>
files to work with older rpm-build, such as when creating software<br>
collections for older OS.<br>
<br>
I use %autopatch in one of my packages (eclipse-m2e-core) so that I<br>
don't forget how it works (or doesn't work :)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Mikolaj Izdebski<br>
Software Engineer, Red Hat<br>
IRC: mizdebsk<br>
</font></span><div class="HOEnZb"><div class="h5">--<br>
devel mailing list<br>
<a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/devel</a><br>
Fedora Code of Conduct: <a href="http://fedoraproject.org/code-of-conduct" rel="noreferrer" target="_blank">http://fedoraproject.org/code-of-conduct</a></div></div></blockquote></div><br><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large">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.</div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large"><br></div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large">I have to wonder if we have a fundamentally bigger problem: our documentation for packaging and the capabilities of RPM is scattered and unloved.</div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large"><br></div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large">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 <a href="https://www.debian.org/doc/manuals/maint-guide/">package maintainers' guide</a> is updated fairly regularly (it was just updated last month!), whereas we don't even have one (well, we've got scattered documents about <a href="https://fedoraproject.org/wiki/Package_Review_Process">package reviews</a>, 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. <a href="https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/index.html">Our packaging guide</a> 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.</div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large"><br></div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large">And of course, <a href="https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html">the RPM Guide</a> 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.</div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large"><br></div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large">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.</div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large"><br></div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large">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.</div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large"><br></div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large">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 <a href="http://backreference.org/2011/09/17/some-tips-on-rpm-conditional-macros/">somewhat vaguely documented elsewhere on the internet</a>, but not well documented where it matters.</div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large"><br></div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:large">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 <i>what</i> RPM can do and how to illustrate it.</div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Neal Gompa (FAS: ngompa)</div></div>
</div><font face="yw-402608bc37fe50adb11a5899295781aeb83d248d-7c9043937830e2958d4acebf3005031e--o" style="display: none;"></font></div>