Re: additions to dpkg-architecture and dpkg-cross
Volker,
As I've already indicated at some point, fixing dpkg-architecture
is a trivial task: just add your stuff to cputable or ostable be off with it.
(I used to do that for some embedded architectures, look for example
at http://www.xs4all.nl/~kurzanov/debian/patches/dpkg-1.13.16-all-1.patch).
The real problem comes when you cross-compile the packages (unless you're
using an inefficient solution like the scratchbox). You have to patch
debian/rules for quite some packages so that dpkg-buildpackage -ai586 works,
and for a few ones it's quite a task.
Another totally different problem comes after you've compiled the
packages using the new architecture and want to generate a rootfs, or
distribute the resulting packages to others using apt/dpkg. Just how
are you planning to set this up without changing apt/dpkg?
Also, as I said earlier, you wouldn't really want to compile all the 30000
packages or so for every architecture variant in the world (there's Gentoo
for that). Just imagine the task of supporting a factor more architectures
for most of these 30000... This would mean 100 architectures rather than 10
as of now, as well as a factor more required developers...
What you want is to have a generic repository (for e.g. i386)
that contains all of the stuff, and a number of specialized repositories
(for e.g. i686) that provide optimized versions of some CPU-intensive
packages. If people are willing to create/use optimized versions, they can
do so, but what they need is a way that allows them to mix generic (i386)
packages with optimized (i686) packages.
Also, the sbuild infrastructure should also allow cross-compiling (which
it currently does not).
So, summarizing I would say these are important steps we need to take:
1. fix dpkg, dpkg-cross (already done, I would say, except for the hierarchic
thing)
2. fix apt (TODO)
3. fix sbuild (TODO)
4. fix debian/rules (to be never completed I'm afraid)
Pjotr
Volker Grabsch wrote:
> On Mon, Jun 26, 2006 at 11:42:40AM +0200, Pjotr Kourzanov wrote:
>> Great that you've put this up to public. Still, for this to be
>> accepted, we need to come up with patches for apt that contain an
>> algorithm that will pick versions of packages matching user's
>> requirements, known architecture hierarchies (i386->i486->...)
>> and available sources.
>
> I hoped this would be accepted even without a change in apt, as
> there are benefits anyways. Better support for optimized packages
> was just one of many examples where more architectures would help.
> Other examples were: support for i586-distributions, support for
> other i386 based OSes which need something better than i486
> (e.g. w32-i586), and a 4th example you'll find later in this mail.
>
> However, if you think we should first improve apt, that's also
> fine for me. However, and later
> improved dpkg-architecture
>
>> Currently, apt is quite dumb in that respect
>> AFAIK, i.e. it only looks at binary-$DEB_HOST_ARCH while it could
>> also look binary-all, binary-$DEB_HOST_ARCH, and
>> binary-$DEB_HOST_SUPERARCH (where $DEB_HOST_SUPERARCH=i386 when
>> DEB_HOST_ARCH=i686) etc.
> [...]
>> It only has one-level hierarchy, but that's just a home-grown sample...
>
> We surely need a more flexible approach. I proposed some in another
> post, please reply to that one.
>
>> Also, dpkg-cross's logic of barfing at conversion between non-equal
>> architecture (names) MUST be changed... It really should also look
>> at the architecture hierarchy and allow for "down-casting" of
>> packages to their cross- counterparts since you really don't want
>> to compile the whole distribution with optimizing/cross compilers
>> (we are not Gentoo are we?).
>
> As the CPU type is part of the Debian architecture name, I don't see
> the problem. When you build a package using dpkg-cross' dpkg-buildpacke
> wrapper, this looks like that:
>
> dpkg-buildpackage -ai586
>
> ... and thus will build an "i586" optimized package using a (hopefully
> installed) i586 cross compiler, while
>
> dpkg-buildpackage -ai386
>
> would create a "i386" optimized package (currently: i486). Thus, I don't
> really see your problem.
>
> BTW, did I already mention that I found it a *very* bad idea to define
> the "i386" Debian architecture as "i486"? This is another good example for
> kludges that result simply on apt's unability to handle multiple
> architectures.
>
>> Furthermore, isn't there a dpkg requirement that all packages
>> installed must have either DEB_HOST_ARCH or "all" as Architecture?
>
> I'm not sure, but as already said: Please let's discuss that in the
> context of my other proposal that I wrote some days before your mail.
> It's a "top-down" proposal starting from the most flexible reasonable
> approach down to what we really need. This ensures we can formulate any
> assumptions we make on the architectures. That isn't easily possible
> in a "buttom-up" approach like yours, i.e. adding one super-architecture,
> later maybe another, later maybe a list, always waiting for counter
> examples before making it more flexible. Sorry for critizising your work,
> but when I read your proposal and your script, my first thought was:
> You're repeating the same fault that has been done with dpkg-architecture
> and from which we (and dpkg-cross) still suffer.
>
>> Should we somehow coordinate our efforts to make this into official
>> apt/dpkg/dpkg-cross?
>
> Whatever proposal we make, it must make apt, dpkg and dpkg-cross work
> together. Such an important step like making apt a multi-platform
> system will surely need patches for all those 3 packages. Getting the
> opinions *and* the support of the maintainers of all 3 packages is very
> important for our success.
>
> That's why I'd like to fix dpkg-architecture first, before any multi-
> architectural ambitions.
>
>
> Greets,
>
> Volker
>
Reply to: