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
On Dec 19, 2012, at 09:20 AM, Chow Loong Jin wrote: >There was some talk on debian-devel about having everything on Debian >imported into Git repositories, which would probably allow for a somewhat >UDD-like workflow for Debian. Unfortunately, I think the usual debian-devel >flames cut it short. That's too bad, because if you think about it, the whole idea of source packaging branches in a dvcs could be a great win for Debian and all its derivatives. The fact that you can do a lot of Debian development using the debianlp: branches on Launchpad shows, I think, that a generic package importer could work across distros. And certainly development of such a tool would benefit from a wider pool of developers. -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 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
On 19/12/2012 00:30, Barry Warsaw wrote: > 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 ^ That's the issue, you see. Anything's better than svn. I personally use the git-buildpackage suite of things for development locally. For packages not maintained in git, I typically use git import-dsc(s) on downloaded .dsc files before starting work. Debian makes this even nicer by having git import-dscs --debsnap which pulls everything from snapshots.debian.org. I used to maintain some packages in DPMT/PAPT back before I became a DD, but it was such a pain to use SVN that I just moved everything to collab-maint. > issue (generated, of course with `bzr diff`). > > Heck, I'd even accept using git if Debian had anything as comfortable > as UDD for me. There was some talk on debian-devel about having everything on Debian imported into Git repositories, which would probably allow for a somewhat UDD-like workflow for Debian. Unfortunately, I think the usual debian-devel flames cut it short. -- Kind regards, Loong Jin signature.asc Description: OpenPGP 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
Mike Carifio wrote: > I would opine that many application developers are more than annoyed, > they're lost. So presenting them with all the various variants and > then asking them to select the right one based on criteria they neither > appreciate nor care about pretty well assures that many will silently > walk away. > I know I'm saying the same thing a different way, but it bears repeating. Oh, indeed. There should be a simple default method presented for the ease of this audience. My fear is only that if we push too far, we lose the ability to handle exceptions, or fall into painful bikeshedding about the "one true way" when in practice the judgement should be on the end, rather than the means. > As I understand it, "policy based" packaging just means "declarative" > and declarative means I can state *what* I want and the toolchain > will figure out the *how*. I don't find that true in practice, however. > I find that I state the what in debian/control, then figure out the how in > debian/rules and then figure out why I didn't say it all properly. So I > google and find a thicket of various approaches and workflows which only > serve to confuse me more. Your understanding matches mine. For purposes of "how", I currently believe that the use of /usr/share/doc/debhelper/examples/rules.tiny should be complete from the perspective of application developers: nearly anything else may well indicate issues with the underlying build system. That said, from the perspective of distribution developers, I think it's important to understand debian/rules as something supporting an API for package creation and interaction to support uncooperative, abandoned, or strongly opinionated upstream developers when others are handling the packaging. Ensuring that we can support both audiences from the same documentation is tricky, but it should be our goal. > I see packaging as something we want the app developer to do. They have > the most knowledge about their application. Given a > reasonable bar, I think they will actually do it. After all, they're > written the application and they want to see it used. > If/when Ubuntu's popularity grows, then the incentive to package will > grow. But let us never forget that this is a tax > they must bear to integrate into Ubuntu. If the tax is too high, they > just won't do it. So we may appreciate a policy-based approach, > the richness of many toolchains and so on. But *they* don't, unless it > makes their lives easier. Note that I'm not saying that > packaging is easy. I'm just saying it can't be a research project for > each rookie developer who wants to take a shot at it. There have been many discussions in the past about generating documentation targeted to recommended procedures for build systems and release procedures for application developers to support the ease of packaging. Ideally, it should be possible to generate distribution artifacts that support near automated packaging for a variety of distributions (for debian-format distributions, this reduces to a need to write the Description and review if multiple binary packages are needed from a source artifact). This goes well beyond packaging and much is unlikely to be specific to an individual distribution, but is likely worth constructing, if there are sufficient members of the class of application developers willing to help define the nature of the issue (I'm not convinced it's something that distribution developers can see well enough to write well). Examples of things to address here might be handling init systems, writing man pages, use of .desktop or .service files, ensuring build systems allow for varied build and installation paths, documenting copyright and licensing assertions, modular configuration file handling, and similar issues. In my opinion, it would be best to have this also be a policy-based model, rather than an implementation-based model, but I suspect a simple set of recommendations can be constructed for common toolchains (e.g. "If you're writing a desktop GUI in ruby, here's what you want to do to make it easily distributable. If you wrote it in python, you likely want to use this entirely different toolchain to do the same thing."), and that such documentation of best practices for application developers would reduce impression of integration tax, as the volume of effort to package something for a given target is significantly reduced. -- Emmet HIKORY -- 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
On 12/18/2012 01:16 AM, Emmet Hikory wrote: > Mike Carifio wrote: >> On 12/17/2012 08:11 PM, Emmet Hikory wrote: >> 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. Emmet, thanks for your quick tutorial. It was useful. I would opine that many application developers are more than annoyed, they're lost. So presenting them with all the various variants and then asking them to select the right one based on criteria they neither appreciate nor care about pretty well assures that many will silently walk away. I know I'm saying the same thing a different way, but it bears repeating. As I understand it, "policy based" packaging just means "declarative" and declarative means I can state *what* I want and the toolchain will figure out the *how*. I don't find that true in practice, however. I find that I state the what in debian/control, then figure out the how in debian/rules and then figure out why I didn't say it all properly. So I google and find a thicket of various approaches and workflows which only serve to confuse me more. I see packaging as something we want the app developer to do. They have the most knowledge about their application. Given a reasonable bar, I think they will actually do it. After all, they're written the application and they want to see it used. If/when Ubuntu's popularity grows, then the incentive to package will grow. But let us never forget that this is a tax they must bear to integrate into Ubuntu. If the tax is too high, they just won't do it. So we may appreciate a policy-based approach, the richness of many toolchains and so on. But *they* don't, unless it makes their lives easier. Note that I'm not saying that packaging is easy. I'm just saying it can't be a research project for each rookie developer who wants to take a shot at it. -- 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 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
