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 > 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)
Steve Langasek wrote: >On Tue, Dec 18, 2012 at 09:19:31PM -0500, Scott Kitterman wrote: >> Steve Langasek 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. I agree it's the consensus that matters. When then current packaging guide materials were developed, there was, I believe a strong expectation that UDD's reliability issues would be worked out in the short term and that UDD would clearly be the better way for most developers (I didn't sit through every single UDD session for multiple UDSs because I thought I wouldn't use it). In the meantime, UDD development has essentially stalled. I think we are in a halfway state where UDD is mature enough to be useful for some, but not for others. To make progress, someone needs to invest resources. IIRC, there was not a single UDD session at the last UDS. 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 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)
Steve Langasek 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 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)
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 diff
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Dec 18, 2012, at 02:08 AM, Scott Kitterman wrote: >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. I'm positive I'm not typical, but I personally find Ubuntu development so much more pleasant than Debian development that I'll use the Debian branches on Launchpad for 90% of my on Debian work. It's only at the "last mile" that I'll switch over to e.g. DPMT's or PAPT's svn repo, or file a patch on a BTS issue (generated, of course with `bzr diff`). Heck, I'd even accept using git if Debian had anything as comfortable as UDD for me. Cheers, -Barry -- 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
Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
Mike Carifio wrote: > On 12/17/2012 08:11 PM, Emmet Hikory wrote: > > packaging guide, I think there is value in being clear that folk who wish to > > package have a plethora of options available: by all means, let's advocate > > the > > latest labour-saving mechanisms, but at the same time, I think we need to > > avoid anything that implies there is some magic one true way to package. At > > least in the current text presented at developer.ubuntu.com, the suggestions > > on packaging new software recommend local compilation, which often hides all > > sorts of issues, although it significantly reduces the apparent setup > > required > > to get involved: I don't believe there is a good answer as to how folk > > should > > do this: some may prefer to set things up to match what they think most > > developers use, and others may just want to get something done. Similarly, > > we're recommending use of dh-make, and then recommending deleting all the > > example files that it produces: this is another case where there may be more > > value in having two paths: one that goes through the dh-make files, and the > > other that just focuses on changelog, compat, control, copyright, and rules > > (of which 60% are trivially generated automatically). Different folk learn > > differently, and as long as we're documenting things that we expect to be > > used not only for new packaging, but also for patching existing packages, > > it behooves us to ensure that we have coverage of all the different ways > > that > > packages might behave, and some guidance on how to discover when to apply > > any > > given rune from some assembled grimoire (assuming it will take some practice > > for folk to learn the tools well enough to remember how to do things without > > looking at their notes). > > > > I come at this differently. Although we may take packaging seriously, I > would say that many devs don't view it > as the main event. They are looking for the one true way to package > because its a means to an end. If there isn't one > or isn't a small number of them, then maybe that's an indication of a > deeper problem. 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. 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
