brainstorming for UDS-N - Application Developers

[Matt Zimmerman]

On Thu, Oct 14, 2010 at 09:14:46PM +0100, Colin Watson wrote:
> On Fri, Oct 01, 2010 at 05:56:27PM +0100, Evan Dandrea wrote:
> > I believe that in order to do this properly, we need to massively
> > simplify our packaging model.  Anything that makes a package
> > non-atomic (hello maintainer scripts) should be thrown out.  Anything
> > that adds needless complexity, equally so.  Packaging needs to be the
> > least important part of the puzzle, not the most difficult, and most
> > certainly not at the core of our own development efforts.
> 
> There are few pressing reasons to change the *binary* package format
> significantly, and many reasons not to.  The core implementation is
> robust yet flexible, knowledge of bits of it is in lots of different
> parts of the core system, we use many of its features in non-trivial but
> mission-critical ways, and you generally only want to have one package
> manager on the system rather than having two of them fighting it out.
> Plus I rather suspect that if we tried to reimplement it then the
> chances are good that we'd end up in a situation where we had two
> package managers neither of which quite met our needs.

I don't think we need to replace dpkg, but I think it might be beneficial to
have more than one subsystem for managing installation of components.  The
requirements are very different at each end of the scale (low-level system
libraries to distributed applications).

(I elaborate on this in
http://mdzlog.alcor.net/2010/07/06/weve-packaged-all-of-the-free-software-what-now/)

While in some cases it may be sufficient to simply ignore the more complex
features offered by dpkg, I think there are fundamental assumptions there
which are much harder to remove (e.g. root privileges).

That said, I agree with you that there are gains to be found in how we work
with source packages.

-- 
 - mdz