<div class="gmail_quote">On Fri, Jul 9, 2010 at 11:57 PM, Ryan Oram <<a href="mailto:ryanoram@trentu.ca">ryanoram@trentu.ca</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">On Fri Jul 9 23:08:14 BST 2010, Joshua Timberman wrote: > Actually, the difference is that sbuild uses schroot with LVM snapshots for the chroot environments. It's quite a nice, elegant system and I prefer it to pbuilder for developing packages. </div>Ya, I can definitely see why sbuild would be used for an automated build environment. It's quite a bit more customizable and better designed for industrial use. These differences aren't really all that relevant to individual developers though. sbuild and pbuilder both build in a chroot environment and if a package will build on one, it will very likely be able to build on the other. I'm probably going to use pbuilder for locally checking if the packages build in a chroot. The commands for pbuilder are very similar to those of debuild and it's quite a bit easier to use. It's more than enough for testing to see if the packages will build when uploaded to Launchpad, which is really all I would use it for. sbuild would be overkill for my individual use. ----- Anyways, looking over both the projects of GetDeb and AppUpdate, they compliment each other more than they duplicate. GetDeb seems to build most of their own packages, while AppUpdate pulls them directly from the developer PPAs. This allows GetDeb to have more packages than AppUpdate, but this also allows for AppDate to have more up to date packages. Comparing the packages present on both GetDeb and AppUpdate, the packages on AppUpdate are a bit newer. My service will build very little on its own, as I feel that building the packages should be the responsibility of the developer. The goal of AppUpdate is to aggregrate the ~20 PPAs many Ubuntu users have in their sources, while giving the packages some extra testing to prevent the breakages that arise when a developer pushes a broken package to their PPA. Its main focus is to be a one stop place for Ubuntu users to get the latest applications for their install, without the risks of broken packages. Links to the AppUpdate PPAs: Stable: <a href="https://launchpad.net/%7Einfinity-team/+archive/appupdate-stable" target="_blank">https://launchpad.net/~infinity-team/+archive/appupdate-stable</a> Testing: <a href="https://launchpad.net/%7Einfinity-team/+archive/appupdate-testing" target="_blank">https://launchpad.net/~infinity-team/+archive/appupdate-testing</a> Thanks, Ryan -- <div><div></div><div class="h5">Ubuntu-devel-discuss mailing list <a href="mailto:Ubuntu-devel-discuss@lists.ubuntu.com">Ubuntu-devel-discuss@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss</a> </div></div></blockquote></div> I am sorry but you are not correct, GetDeb only does packaging when such is required, we try to avoid redundant work and package forking. Re-using Ubuntu, Debian and PPAs building rules is a requirement if you intend to minimize dependency conflicts with official packages. However we will not use a developer's PPA or someone else build rules if we don't find them to have sufficient quality. We did a lot packaging because we have provided many applications before they were packaged anywhere else. João Luís Marques Pinto GetDeb Team Leader <a href="http://www.getdeb.net">http://www.getdeb.net</a> <a href="http://blog.getdeb.net">http://blog.getdeb.net</a>