Please don't, there have been a whole plethora of confused users not
understanding why certain packages aren't installable because they
installed with a method that didn't include i386 such as debootstrap.
Also, I have run into a significant number of customers who use Wine
on Ubuntu Server. This would 100% break for them.
It's only "Trivial to add" if you know exactly what to do here, and
understanding multiarch internals is not something even most syadmins
bother to do precisely because we've done such a good job at making
apt just work.
On Thu, Feb 13, 2014 at 1:26 PM, Adam Conrad <adconrad@ubuntu.com> wrote:
> On Thu, Feb 13, 2014 at 06:24:18AM -0500, Scott Moser wrote:
>>
>> I just did an ISO server install of trusty server, and I end up with
>> 'i386' in the output of:
>> $ dpkg --print-foreign-architectures
>> i386
>
> It's been this way since (at least) precise on all amd64 installations.
>
>> I really wish we'd have done it earlier, but I really think that most of
>> the time this is just a waste of network traffic on 'apt-get update' on a
>> server. If people want i386 packages on amd64, its trivial for them to
>> re-enable it.
>
> So, if there's concensus that "server" installations shouldn't have a
> foreign arch enabled by default, we'd need to sort out how to fix this.
>
> Right now, it's done in the dpkg postinst, which has no clue whatsoever
> what's a server or a desktop. One could say "well, just enable it in
> ubiquity", but that cuts out all the desktop installations that are done
> via netboot/d-i methods.
>
> So, perhaps one could tear out the dpkg postinst snippet and put it in
> the postinst of an empty package called "i386-multiarch" and add that
> to the desktop-common seed, but the idea of having a package installed
> whose sole purpose is to execute a postinst on first install, and then
> lie inert for the rest of the life of your system also rubs me slightly
> the wrong way.
>
> Anyone have any better options (or arguments why server should get the
> same multiarch settings as desktops and, thus, the status quo is fine)?
>
> ... Adam
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
