Re: Styles of Packaging (was: Deprecating the wiki-based, Packaging Guide)
Hi, Le 20/12/2012 13:00, ubuntu-devel-requ...@lists.ubuntu.com a écrit : Date: Wed, 19 Dec 2012 11:16:49 -0500 From: Barry Warsaw ba...@ubuntu.com To: ubuntu-devel@lists.ubuntu.com Subject: Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide) Message-ID: 20121219111649.58ce8...@resist.wooz.org Content-Type: text/plain; charset=us-ascii On Dec 18, 2012, at 06:05 PM, Steve Langasek wrote: UDD poses a different set of problems. I'm not sure how relevant it is to the upstream developer who just wants to package their software; at the very least, I think the developer docs should explicitly deal with the possibility that the upstream has already made a different VCS choice that's not bzr. The packaging guide has a bit of a schizophrenic heritage, and it's not quite sure what audience it's trying to reach. Is it upstream developers who just want to package their software? Is it drive-by Ubuntu contributors who want to gain some experience fixing a bug or scratching their own itch? Is it the experienced developer who whats a reference to preferred tools? Maybe I can share my experience on how I've seen and used the packaging guide in the past year, coming from complete debian packaging ignorance. I've looked at the guide as a best practice from the Ubuntu community on how things should be done correctly to produce good quality packaging. Since my work is solely working on existing packages, it was a great help in understanding why things are done a certain way and how to continue to do things adequately. It was a great help in doing a fast ramp up to packaging and I still use it regularly to confirm part of my workflow. Maybe a good understanding of the target audience might help to stear some of its content. Kind regards, ...Louis -- Louis Bouchard Backline Support Analyst Canonical Ltd Ubuntu support: http://landscape.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Dec 18, 2012, at 06:05 PM, Steve Langasek wrote: UDD poses a different set of problems. I'm not sure how relevant it is to the upstream developer who just wants to package their software; at the very least, I think the developer docs should explicitly deal with the possibility that the upstream has already made a different VCS choice that's not bzr. The packaging guide has a bit of a schizophrenic heritage, and it's not quite sure what audience it's trying to reach. Is it upstream developers who just want to package their software? Is it drive-by Ubuntu contributors who want to gain some experience fixing a bug or scratching their own itch? Is it the experienced developer who whats a reference to preferred tools? Certainly, the original UDD guide (from which much of the current packaging text was lifted) was written for experienced developers wanting to understand how to use UDD to maintain packages for Ubuntu. And where Ubuntu development is concerned, I regret that I have to agree with Scott that the lack of reliability for the existing UDD branches is a problem, and one that doesn't seem to be getting better over time. So while I personally favor the UDD workflow (and fervently disagree with Scott's claim that it's a more complex toolset), I think we do need to reconsider if it's actually beneficial to steer developers down this path. Whether or not there's a consensus that we should be using UDD, it's no use to new developers if it doesn't actually work. I think it's only going to get better if some of us enthusiasts step up to help start fixing things. I'm not entirely sure where to start, but that a topic for the udd mailing list, not this one. -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Tue, Dec 18, 2012 at 03:16:13PM +0900, Emmet Hikory wrote: While it may appear that way at first glance, this is very much an intentional consequence of policy-based packaging, which Ubuntu inherits from Debian. By having packaging judged against policy, rather than against some arbitrary implementation, we are free to continuously innovate in our use of tools to improve our packaging. Innovations that lead to interesting consequences frequently become policy, such that all other packaging toolchains in the archive are expected to support the expected results (or be retired). However, as this has been an ongoing process of competitive improvement of the several toolchains over more than 20 years, and as many packages have not been updated in some time (this may be by design: e.g. mpi-specs, which likely won't be updated for many more years to come), and many how to package documents are floating around the internet, this means that every possible experimental means of packaging is documented somewhere (and may show up in your favorite search engine), and many of them are used for packages extant in the current archive. There is definitely a set of tools that are currently the most popular in the Debian archive, and these integrate well with a set of tools being developed under the Ubuntu Distributed Development moniker, which combination may well likely be that which is recommended by the Ubuntu Packaging Guide under development: as such, this recommendation [0] is what ought be followed by the class of developers for whom packaging is a means to an end (as they are often focused on a specific piece of software). For folk who might focus on packaging as an end, preferring the role of distribution developer to that of application developer, there is a need for a greater understanding of the underlying policy and the massive variety of tools by which this policy may be implemented. People who are aiming to contribute to Ubuntu as a distribution absolutely need to master a different set of skills than those who just want to package up their own software. In terms of developer documentation, I think the important goals are that: - We make sure everyone has a handle on the second category before they tackle the first category. - We avoid annoying or distracting developers who only care about the second category with information that's only relevant in the first category. - We ensure that developers who are looking to participate in Ubuntu development can find the information they need from the same entry point. - We ensure that the recommendations that we're giving developers for creating packages for their software aren't at odds with the consensus among experienced Ubuntu developers about how a package should look. I think the current Ubuntu Packaging Guide is doing a reasonably good job of walking this line. Where it isn't, I'm sure bug reports are welcome. Where this is understandably annoying for the application developer is that the recommendation is subject to change over time, as newer tools are developed and adopted: we tend to select toolsets that provide the most automation while leaving us the facility to make local exceptions to standard processing as appropriate for specific packages, which may appear to require an application developer to relearn from scratch every so many years. In practice, the lifecycle of a toolset is typically much longer than the period during which it is the most popular for use, and it is rare for toolsets to be entirely retired (although in some cases the maintainer of the packaging toolset may declare they no longer intend to support it, and it will only live on if someone else is willing to update it to support current policy). As a result, once one learns some means of packaging, one may usually continue with that method for a fairly long time without need to change unless one is excited about new features of a newer toolset. Where package tooling has changed recently, it has mostly been about incremental improvements rather than revolutionary changes. At the packaging level, http://people.debian.org/~cjwatson/dhstats.png shows that dh(1) has had dominant mindshare for over 3 years (shown by the constant growth in usage), and if it doesn't quite yet represent the way the majority of packages in the archive are done, this has more to do with the inertia of existing packages than with any lack of consensus. Prior to the advent of dh(1), there *was* a distinct lack of consensus, with developers divided roughly equally between cdbs and debhelper camps. So I do think it's important that any documentation that's teaching people how to package focus on dh, and explicitly relegate non-dh packaging to the category of here's what to do if you need to work on an existing package that doesn't follow best practices. UDD poses a different set of problems. I'm not sure how
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Tue, Dec 18, 2012 at 02:08:04AM -0500, Scott Kitterman wrote: 1. While there are sponsors that prefer branches over debdiffs/source packages uploaded somewhere, I don't know of any that will only sponsor branches. The reverse is not true. There are developers that don't do UDD sponsoring. By pursuing this path, new packagers limit the potential candidates to sponsor packages. If there is a consensus that new packagers should be using UDD, we shouldn't let that consensus be held hostage by dissenters that refuse to use UDD. But as per my previous message, I agree that UDD reliability here is a major problem, and no one is well served by developer documentation describing a non-existent utopia instead of the way things actually are. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
Steve Langasek steve.langa...@ubuntu.com wrote: On Tue, Dec 18, 2012 at 02:08:04AM -0500, Scott Kitterman wrote: 1. While there are sponsors that prefer branches over debdiffs/source packages uploaded somewhere, I don't know of any that will only sponsor branches. The reverse is not true. There are developers that don't do UDD sponsoring. By pursuing this path, new packagers limit the potential candidates to sponsor packages. If there is a consensus that new packagers should be using UDD, we shouldn't let that consensus be held hostage by dissenters that refuse to use UDD. But as per my previous message, I agree that UDD reliability here is a major problem, and no one is well served by developer documentation describing a non-existent utopia instead of the way things actually are. I don't think such a consensus, outside of the small group of people that invested time in the packaging guide, exists. The Kubuntu team does not use it and last I checked Ubuntu Desktop didn't either. There are people the use UDD, of course, but also large numbers that don't. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Tue, Dec 18, 2012 at 09:19:31PM -0500, Scott Kitterman wrote: Steve Langasek steve.langa...@ubuntu.com wrote: On Tue, Dec 18, 2012 at 02:08:04AM -0500, Scott Kitterman wrote: 1. While there are sponsors that prefer branches over debdiffs/source packages uploaded somewhere, I don't know of any that will only sponsor branches. The reverse is not true. There are developers that don't do UDD sponsoring. By pursuing this path, new packagers limit the potential candidates to sponsor packages. If there is a consensus that new packagers should be using UDD, we shouldn't let that consensus be held hostage by dissenters that refuse to use UDD. But as per my previous message, I agree that UDD reliability here is a major problem, and no one is well served by developer documentation describing a non-existent utopia instead of the way things actually are. I don't think such a consensus, outside of the small group of people that invested time in the packaging guide, exists. There may or may not be such a consensus. But the consensus is what matters, and the above argument is therefore irrelevant to whether UDD should be the recommended workflow. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Tuesday, December 18, 2012 03:16:13 PM Emmet Hikory wrote: There is definitely a set of tools that are currently the most popular in the Debian archive, and these integrate well with a set of tools being developed under the Ubuntu Distributed Development moniker, which combination may well likely be that which is recommended by the Ubuntu Packaging Guide under development: as such, this recommendation [0] is what ought be followed by the class of developers for whom packaging is a means to an end (as they are often focused on a specific piece of software). For folk who might focus on packaging as an end, preferring the role of distribution developer to that of application developer, there is a need for a greater understanding of the underlying policy and the massive variety of tools by which this policy may be implemented. I think UDD based packaging is a very poor recommendation for this class of packagers for several reasons: 1. While there are sponsors that prefer branches over debdiffs/source packages uploaded somewhere, I don't know of any that will only sponsor branches. The reverse is not true. There are developers that don't do UDD sponsoring. By pursuing this path, new packagers limit the potential candidates to sponsor packages. 2. For developers that have a significant interest in a specific package, we generally recommend that they submit that package to Debian (although it might be accepted to Ubuntu first). Debian doesn't use Ubuntu UDD (in fact the acronym UDD has a completely different meaning in a Debian context). So if developers learn UDD style packaging they have to learn a new set of tools to work with Debian. 3. Ubuntu UDD has sufficient reliability issues that it is not rare for branches to be out of date. As soon as this happens, the new developer then has to get familiar with traditional tools (which are not documented in the packaging guide - last I looked for them anyway). I know UDD is working for some Ubuntu developers, but I don't think it's mature enough to be the first set of tools we give new people to use. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
