On Thu, Jul 8, 2010 at 7:20 PM, Joao Pinto <[email protected]> wrote: > The last time I have checked pbuilder used chroots just as sbuild does, > where can I read about the VM technology used for the PPAs ? > How does it improve package quality compared to a regular chroot based build > ? > The dependency and scripts validation being specific to pbuilder is not > correct, that depends on installing the package in a clean chroot, something > that we do with sbuild. > > I am sorry, but again that is not correct, please check > "https://wiki.ubuntu.com/MOTU/Contributing";, search for "Build the package > with sbuild or pbuilder" .
I apologize. I was completely mistaken. It seems as if Ubuntu and Debian allow the use of sbuild as well, just not vanilla debuild. Launchpad also uses sbuild, as the Ubuntu developer said in a previous reply. Looking my Launchpad build logs, I can verify this. Launchpad does run lintian afterwards, though I suppose your building process can easily add this step. However, on an end user machine, pbuilder is a bit more convient than sbuild as it automates a lot more, making it easier to check if your package will compile in a chroot environment. This is a bit irrelevant in this case, though, I do recommend developers use pbuilder in their package testing due to being a bit easier to use. In reply to Soren, everything being on external virtual servers is also an example of making the creation of these packages as easy and transparent as possible for developers, while keeping all the safety measures and checks in place. It provides a standard environment that developers can easily use to create and their packages. It gives developers one less thing to worry about. This may be a side effect, but it's certainly a good one. > We avoid to provide information the main page which is useful for a few > users, we do have a "Contact" link :) You should add a tiny link on the front page, so others won't have to ask. :P > The GetDeb repository is just as integrated as a PPA, it's a regular 3rd > party repository, we don't use PPAs because: > 1) our build system is prior to PPAs > 2) some of our packages are not acceptable per PPA's software licence > requirements > 3) we have more flexibility to integrate features which wouldn't have much > use on the PPA scenario I can see the purpose behind why you don't use Launchpad. However, it is a huge convenience for developers as it transparently shows them the build process and even tells them via e-mail when their build has failed. I think it is also important to standardize the build process for Ubuntu apps and allow for users to easily see the steps taken in generating and testing the packages. The restriction of Launchpad not being able to be used with closed software is a bit of a flaw, however, this would also encourage users to look at open source alternatives. It is a bit inappropriate for closed applications to be included in an auto update service, as the methods of package generation and the source code can not be parsed during testing. I feel that including closed sourced applications in such a service is a security flaw. I guess this is example of the differing priorities of our projects, though these differing priorities are certainly not a bad thing. > The PPA does not validate if a package is Ubuntu/Debian policy compliant, > such is not possible in a fully automated fashion, lintian helps a lot but > does not replace a human reviewer. It does allow easy access to the logs, however, so developers can review these recommendations easily online. My service will require each package be put into a week long testing phrase so that anything that automation doesn't catch will have a catch to be caught by a tester. >> I would be more than happy to assist your project and help integrate >> it into the Launchpad and PPA processes. However, this would be a huge >> restructuring of your project, requiring many time-consuming changes. It adds transparency and accesible documentation for testers. This is crucial for the week long testing period, as it will allow me and the testers to directly advise the developments on what changes need be made on their packages and allows us to make suggestions. ----- With all of this in mind, our projects still have plenty of room for collaboration. I am certainly interested in apt-portal and there is nothing stopping us from sharing package sources. However, I do feel that integration with Launchpad is very important to developers and users alike as it will allow better communication. I'm a believer in keeping the process out in the open, as that is the only way it can be made better. I respect your project and appreciate the progress it has enabled by allowing developers to release their applications outside of the Ubuntu system, which has been at times too strict and a bit unforgiving. However, the lack of Launchpad integration is major sticking point and the major reason why Ubuntu AppUpdate was created in the first place. This doesn't mean I'm not willing collaborate to with your team on side-projects (in fact expect a bit of collaboration with the apt-portal project), but it does mean that my project will likely stay separate. Good luck, Ryan -- Ubuntu-devel-discuss mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
