I've probably said it publicly before, so I'll say it again: what Debian and other distributions need are good, automated ways of packaging upstream code (which may mean more standardisation upstream), and a way for non-privileged users to build on the foundations provided by existing packages, potentially obtained from newer distribution versions, so that they may build, install and run the latest (not yet officially packaged) software if they need to, rather than having to configure, build and install every last dependency by hand.
Posted Apr 1, 2012 8:04 UTC (Sun) by pabs (subscriber, #43278)
[Link]
As a Debian maintainer since 2005, I have come to think that automated packaging just isn't possible. In the ideal world, maybe but we don't live in an ideal world. For a start there is a lot of this going on in the area of build systems:
With debhelper 7 we are pretty close, but there are build systems it doesn't support yet and many packages still need override_* targets, even some packages that use plain autotools.
Then there is all the packaging stuff that needs a human; good package descriptions, copyright/licensing stuff, communication with upstream etc.
Free is too expensive (Economist)
Posted Apr 1, 2012 17:45 UTC (Sun) by pboddie (subscriber, #50784)
[Link]
Having been through the Debian packaging process recently, I certainly appreciate that there's a gulf between what upstream software provides, even with a helpful author and a well-engineered project, and the finished packaged "product" that has all the documentation and policy-compliance that end-users expect.
But while I understand that there's never going to be a magic button to press that takes just about any source code and produces a package, there could be ways of helping people achieve the technical and procedural standards required by downstream developers and ease the passage of their own code into distributions.
In certain circles, people would be pushed towards using some development environment or other that constrains the developer and generates any necessary boilerplate, although this doesn't ensure that the result is high quality. What would be more compatible with most Free Software development is just the acknowledgement that although distributions have differing practices and can be more or less rigorous than each other on certain issues, the general objectives are mostly the same.
From that point, I think that tools could help people make their software easier to package, such as those developed for Python, despite various baked-in features that have to be overridden because the tools want to do everything including things that they really should have no control over.