On Wed, Oct 09, 2013 at 11:18:40AM -0700, Robert Park wrote:
> Up until a couple of days ago, I was blissfully ignorant of the fact
> that some packages need to have different distropatches depending on
> which arch the package is built for. Unfortunately, the following
> debian/rules snippet has come to my attention:
> http://paste.ubuntu.com/6214717/
> This can currently be found in lp:cordova-ubuntu,
> lp:cordova-ubuntu-tests, lp:signon, and possibly others. Does anybody
> know where this originated? Everybody I've asked so far has admitted
> that they just copied it from somebody else.
> I would *hope* that it is obvious to everybody why this is a horrible
> abomination that needs to be killed with fire, but just in case you
> don't see the problem here, I'll explain. It is an enormous
> maintainability nightmare. It re-invents precisely what it is that
> quilt is supposed to be doing for you, in a way that is sensitive to
> the implementation details of quilt itself. What if quilt's behavior
> changes in the future? This snippet will have to be found and updated
> everywhere that it exists. What if a bug is found in this snippet?
> Again it will have to be found and fixed everywhere. It becomes a
> sloppy copy&paste hackjob.
> Instead, I would like to propose an alternative that is superior
> because it does not rely on any quilt implementation details, and is
> written in half as many lines of code:
> http://paste.ubuntu.com/6214750/
> The only change necessary to make this work is to rename the existing
> debian/patches/series to debian/patches/series.all, and make sure that
> the debian directory does not ship with a debian/patches/series file
> (its presence in the source tree would prevent it from being generated
> at build time).
I have to agree with Colin here. One of these implementations may be
shorter and cleaner than the other, but both are papering over the real
problem: releasing packages whose source is not properly cross-architecture.
There are negative externalities here well beyond the problem of making
our packages incompatible with 3.0 (quilt) format (and incompatible with
Debian Policy's more general guidance that "dpkg-source -x should be all you
need to unpack the source").
Almost all of this kind of thing that I see popping up involves conflating a
CPU architecture (armhf) with a software platform (Ubuntu Touch). It's
understandable that developers would employ such quick&dirty tricks to get
their code to do the right thing across architectures, but it needs to be
understood that they *are* dirty. The broader vision for Ubuntu Touch /
Unity is one of convergence. Not only should our packages be ready for a
world in which we're running a desktop environment off our converged armhf
phone, they should also be ready for us running the Ubuntu Touch stack on
x86, too!
The Ubuntu Core team has been working to prepare images of Ubuntu Touch
targeting the Android goldfish emulator target (based on qemu). While the
first iteration of this will be using armhf, I expect that down the line we
will migrate to running the goldfish x86 target for better performance. But
to do that, we need to have a code base that's free of wrong architecture
assumptions.
In the case of signon, I see two possible cross-platform solutions:
- make signond support reading its configuration from multiple files (e.g.,
/etc/signon.d/*.conf), and have the signon-keyring-extension package
provide the integration to enable the storage backend, or
- have signond autodetect the correct backend at runtime.
Either way, this really shouldn't be hard-coded in the signond package on a
per-architecture basis.
Cheers,
--
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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
