Re: Brief (and early) ode to fedpkg
On Mon, Jan 24, 2011 at 9:38 PM, Bernie Innocenti ber...@codewiz.org wrote: On Mon, 2011-01-24 at 20:38 +, Peter Robinson wrote: Oh, and the ability to push builds to bohdi while sitting comfortably in our shell sessions would also be great. try fedpkg update Cool! Then, can I make another wish? Some documentation :-) Try fedpkg --help and it gives you a basic overview of all the commands available. If there's options for the sub commands fedpkg command --help will give you the details of that not perfect documentation but more than enough to work most of it out :-) Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Brief (and early) ode to fedpkg
On 1/24/11 1:38 PM, Bernie Innocenti wrote: try fedpkg update Cool! Then, can I make another wish? Some documentation:-) There has been a patch submitted to generate a man page. I need to review it though as it's a fairly big patch. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Brief (and early) ode to fedpkg
On 1/24/11 7:21 PM, Bernie Innocenti wrote: On Mon, 2011-01-24 at 16:46 -0800, Jesse Keating wrote: That's a bit of a struggle, as there are times when you want something in the scm changelog that isn't really appropriate for the rpm changelog, like fixing a typo in the specfile between build attempts. We do provide the clog facility so that one can re-use the spec changelog for the SCM changelog when appropriate. I've also explored a bit using a %include directive to include contents from a changelog file, one that might be auto-generated from source control, but I didn't go very far with it. Basically I view the scm changelog as data that is relevant and important to your fellow maintainers, where as the rpm changelog is data that is relevant and important to the rpm consumers. While there is some overlap, they are not the same consumers. The old KDE 1.0 CVS repository used a sophisticated commit hook which would interpret tags in the comments such as CVSSILENT, CVSFEATURE or CVSSECURITY to suppress the notification email or add more recipients on cc. Couldn't we do something similar for suppressing entries we don't want to see in the package changelog? Sure it's possible, that'd have to live server side though, unless we put the logic into fedpkg itself. With git the commit happens and then at some future time you ship off your commits to the remote server. Besides: the changelog feature of rpm always stroke me as something so... gross! It is part of the package metadata, but due to size considerations it's not really part of the primary repodata. For multi-package specs, you end up with multiple copies of the same changelog in the rpm database. Moreover, RPM-based distributions use different incompatible formats for %changelog! Not to mention that the % changelog section is where you get 90% of the merge conflicts when porting changes between branches. Well you're talking about yum and rpm here, yes we strip out changelog data from the yum metadata because it's frequently downloaded. Once on your system though the changelog lives in the rpm database. As to whether or not it takes up more space if you have multiple subpackages installed is a question for the rpmdb folks. Seems like a fairly easy thing to just keep a reference. By contrast, .deb packages simply include a compressed text file: /usr/share/doc/$PKG/changelog.gz. Why couldn't we switch to something similar and thus remove a lot of complexity from the rpm toolchain? (the package changelog is maintained manually, but Debian doesn't have a distro-wide package VCS). Nothing, except massive amounts of coordination around upstream rpm, who are busy with other rather more important tasks right now :) I'm just throwing around a bunch of ideas to think about... simplifying the fedora packaging workflow is an important goal, imho. Indeed. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Brief (and early) ode to fedpkg
I was a git hacker, so the noise around fedpkg drew my attention. Now that I'm working on preparing some patched and custom RPMs for OLPC's XS, I am starting to use it, and I have to say, it rocks. Haven't heard other OLPC'ers talk about it... if you're not using it, it's worth a good shot. What's so good? With the old CVS, it was hard to prep a 'forked' spec, say adding 2 patches to it, and track Fedora's CVS. And the Fedora specs relied on a 'common' set of scripts that were pulled from CVS too, so if you put the spec in git, it wouldn't build. Many olpc packages ended up with odd and disparate makefiles to make building them easier. That's ended up being a drag, each package has its own build infra, and they all differ from Fedora's. Fedpkg has consolidated Fedora's common stuff into its code, so all you need is a git checkout with a spec file and some patches right there. And it'll build your stuff, locally, via koji, whatever. Real Nice. And it's a much smoother path to get the packaging itself into Fedora (or EPEL, as it's more likely with my stuff). cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Brief (and early) ode to fedpkg
On Mon, 2011-01-24 at 15:21 -0500, Martin Langhoff wrote: Fedpkg has consolidated Fedora's common stuff into its code, so all you need is a git checkout with a spec file and some patches right there. And it'll build your stuff, locally, via koji, whatever. Real Nice. Yeah, fedpkg git are the best things that happened to Fedora in many years... I just wish we could get rid of the redundant changelog in the spec file. Oh, and the ability to push builds to bohdi while sitting comfortably in our shell sessions would also be great. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Brief (and early) ode to fedpkg
On Mon, Jan 24, 2011 at 8:35 PM, Bernie Innocenti ber...@codewiz.org wrote: On Mon, 2011-01-24 at 15:21 -0500, Martin Langhoff wrote: Fedpkg has consolidated Fedora's common stuff into its code, so all you need is a git checkout with a spec file and some patches right there. And it'll build your stuff, locally, via koji, whatever. Real Nice. Yeah, fedpkg git are the best things that happened to Fedora in many years... I just wish we could get rid of the redundant changelog in the spec file. Oh, and the ability to push builds to bohdi while sitting comfortably in our shell sessions would also be great. try fedpkg update Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Brief (and early) ode to fedpkg
On 1/24/11 12:35 PM, Bernie Innocenti wrote: On Mon, 2011-01-24 at 15:21 -0500, Martin Langhoff wrote: Fedpkg has consolidated Fedora's common stuff into its code, so all you need is a git checkout with a spec file and some patches right there. And it'll build your stuff, locally, via koji, whatever. Real Nice. Yeah, fedpkg git are the best things that happened to Fedora in many years... Thanks! I just wish we could get rid of the redundant changelog in the spec file. That's a bit of a struggle, as there are times when you want something in the scm changelog that isn't really appropriate for the rpm changelog, like fixing a typo in the specfile between build attempts. We do provide the clog facility so that one can re-use the spec changelog for the SCM changelog when appropriate. I've also explored a bit using a %include directive to include contents from a changelog file, one that might be auto-generated from source control, but I didn't go very far with it. Basically I view the scm changelog as data that is relevant and important to your fellow maintainers, where as the rpm changelog is data that is relevant and important to the rpm consumers. While there is some overlap, they are not the same consumers. Oh, and the ability to push builds to bohdi while sitting comfortably in our shell sessions would also be great. As another has mentioned, there is an update target for fedpkg. Luke Macken ported the code that was in the Make system in CVS. I believe it still has some rough edges but should work. If there is something deficient there, please to file a ticket and we'll look at improving it. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Brief (and early) ode to fedpkg
On Mon, 2011-01-24 at 20:38 +, Peter Robinson wrote: Oh, and the ability to push builds to bohdi while sitting comfortably in our shell sessions would also be great. try fedpkg update Cool! Then, can I make another wish? Some documentation :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Brief (and early) ode to fedpkg
On Mon, 2011-01-24 at 16:46 -0800, Jesse Keating wrote: That's a bit of a struggle, as there are times when you want something in the scm changelog that isn't really appropriate for the rpm changelog, like fixing a typo in the specfile between build attempts. We do provide the clog facility so that one can re-use the spec changelog for the SCM changelog when appropriate. I've also explored a bit using a %include directive to include contents from a changelog file, one that might be auto-generated from source control, but I didn't go very far with it. Basically I view the scm changelog as data that is relevant and important to your fellow maintainers, where as the rpm changelog is data that is relevant and important to the rpm consumers. While there is some overlap, they are not the same consumers. The old KDE 1.0 CVS repository used a sophisticated commit hook which would interpret tags in the comments such as CVSSILENT, CVSFEATURE or CVSSECURITY to suppress the notification email or add more recipients on cc. Couldn't we do something similar for suppressing entries we don't want to see in the package changelog? Besides: the changelog feature of rpm always stroke me as something so... gross! It is part of the package metadata, but due to size considerations it's not really part of the primary repodata. For multi-package specs, you end up with multiple copies of the same changelog in the rpm database. Moreover, RPM-based distributions use different incompatible formats for %changelog! Not to mention that the % changelog section is where you get 90% of the merge conflicts when porting changes between branches. By contrast, .deb packages simply include a compressed text file: /usr/share/doc/$PKG/changelog.gz. Why couldn't we switch to something similar and thus remove a lot of complexity from the rpm toolchain? (the package changelog is maintained manually, but Debian doesn't have a distro-wide package VCS). I'm just throwing around a bunch of ideas to think about... simplifying the fedora packaging workflow is an important goal, imho. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
