On Tue, Jul 22, 2008, Neil Williams wrote:
> Equally, I am upstream for various projects that have packages in Debian
> - I am happy to use the BTS for upstream issues with those packages but
> I know of many upstreams who would not consider scanning the BTS and
> expect Debian to forward bugs to them. This is perfectly understandable
> and absolutely not a problem in Debian. Maybe Ubuntu should do more to
> communicate with Debian about Debian-native packages? Debian is the
> upstream of emdebian-tools, Debian is where I listen out for problems
> and issues with my native Debian packages. I am no more likely to go
> rummaging in Ubuntu than other upstream teams would be to go scanning
> the BTS.
[...]
> True, but there are areas where native Debian packages may need more
> support from Ubuntu:
> 1. Forwarding Ubuntu bugs to the BTS - treating Debian as the upstream.
Sure; Ubuntu should forward bugs upstream. (Various team in Ubuntu do
so for actively used packages; it seems emdebian-tools didn't find an
Ubuntu maintainer / contributor interested in forwarding bugs yet
though.)
> > 3) "emdebian-tools is not intended for Ubuntu but I don't have a way of
> > encoding that in the package"; I think it's hard to tell from your side
> > what derivatives would /not/ be interested in; I believe there are very
> > little packages which are truly distro specific: perhaps keyrings or
> > meta packages, and I'm not even sure.
>
> True (note that emdebian-tools does include a keyring package). There
> probably are very few packages in this kind of situation - typically
> native Debian packages that have a high dependency on Debian
> infrastructure. Identifying such packages is not trivial.
Yes, and I would add it's quite subjective. Even keyring packages
aren't clear: consider the recent backports' keyring package. Or
simply the example I already gave of debootstrap-ing Ubuntu from Debian
or vice-versa.
> > Consider debootstrapping Debian
> > from Ubuntu or vice versa, pbuilding in the same combinations, or
> > creating virtual machines. The same could apply to emdebian tools; of
> > course there's no official Ubuntu arm port, but did you know that Nokia
> > built many of the last Ubuntu releases for arm with almost zero
> > modifications? Ubuntu is also preparing an armel port. So I'm not
> > sure it's easy to tell whether emdebian is suitable for Ubuntu or not.
>
> Not sure if those builds were done natively or as cross-builds.
> Cross-building support is the issue here, in particular obtaining the
> cross-architecture dependencies as pre-built, compatible, binary
> packages.
The unofficial Ubuntu arm port (ports actually) I mention were done
natively for reasons outlined in the article (many packages don't cross
build properly):
<http://www.linuxdevices.com/news/NS2097004728.html>
NB: this isn't actually Debian's "arm", but uses this dpkg architecture
> > Certainly using the criteria of native versionning of a package is not
> > a good criteria to decide.
> True, but there are areas where native Debian packages may need more
> support from Ubuntu:
[...]
> 2. Removing those few packages that are both native Debian and highly
> Debian dependent. This is a manual step.
This is quite subjective. Even Ubuntu has derivatives itself (see
above port example). But I agree it might be best to simply remove
some packages which might be irrelevant, dangerous, or useless clutter
for Ubuntu users, or a waste of resources in general.
> > So, yes, Ubuntu Mobile wouldn't make a good use of Emdebian tools
> > because it's unrelated; however there might be interest for these tools
> > from an Ubuntu environment.
> To do so, the binaries must exist to prepare using apt-cross/dpkg-cross.
> Currently, that is not the case and I don't think that is going to
> change before ibex is released. (If it does, by the sound of it this
> would only happen for armel and the Emdebian patches would still fail to
> apply.)
I can't tell how it will be at the time of the intrepid release, but as
you could witness with the third-party port, it's entirely possible
that a third party provides a ported archive somewhere. And it's still
useful to run the tools again the Debian archive from an Ubuntu
environment.
> > i) all the packages you mention (patched packages and tools) are being
> > imported and updated in Ubuntu regularly
> but are not available in Ubuntu as ARM binaries.
(But might be at any time from anybody, and will hopefully soon be
available as armel binaries.)
> > ii) you might want to build Debian based images from an Ubuntu env
> debootstrap can do that.
I meant: you might want to run emdebian-tools from an Ubuntu
environment against the Emdebian / Debian archives.
> > iii) an Ubuntu arm port might as well exist outside of the Ubuntu
> > official mirrors, just like the Nokia one, or might come to life
> > later on
>
> And mips, mipsel, uClibc-arm, and the rest?
> emdebian-tools is not a one-architecture support package, it can support
> any architecture that Debian can support. Making Ubuntu support the same
> range is more than a little pointless.
Anybody can port Ubuntu to these; these are not needed to make
emdebian-tools useful for people targetting arm! :-)
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
