On 12/17/2012 08:11 PM, Emmet Hikory wrote: > Andrew Starr-Bochicchio wrote: >> On Mon, Dec 17, 2012 at 4:53 PM, Benjamin Drung <[email protected]> wrote: >>> Am Montag, den 17.12.2012, 16:01 -0500 schrieb Andrew Starr-Bochicchio: >>>> 1) Send a last-call anouncement to ubuntu-devel requesting bug reports >>>> about any missing material. Announce steps 2 and 3 will take place >>>> after one month. >>>> 2) Move the entire PackagingGuide wiki namespace en masse to >>>> PackagingGuideDeprecated. >>>> 3) Redirect wiki.ubuntu.com/PackagingGuide to >>>> developer.ubuntu.com/packaging/html/ >>>> 4) After six months (one full development cycle) >>>> PackagingGuideDeprecated will be deleted. >>>> >>>> This is the mail referred to in step 1. In one month, I will move the >>>> entire PackagingGuide wiki namespace enmass to >>>> PackagingGuideDeprecated and set up a redirect. If you feel that there >>>> are any critical pieces of information that are missing from the >>>> Sphinx-based Ubuntu Packaging Guide, now is the time to file bugs (and >>>> provide patches). [4] >>> Will these bugs tracked and fixed before step four? We should only >>> remove the wiki based guide if all missing pieces from it are available >>> in the Sphinx-based packaging guide. >> That said, I do think it is important to point out that "all missing >> pieces" will never be completely ported to the new guide. A large >> part of the reason for making the new guide in the first place has >> been to streamline it, making opinionated decisions of what to >> include, and eliminate the "choose your own adventure" style of the >> old guide. For instance, do we really need to discus desktop files and >> POD based manpages in the Packaging Guide? > While I'm all in favour of a return to a managed (and packagable) > 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. -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
