Re: remove i386 from foreign arch on server install?
I propose ( for the future release at least ) to audit all of this and compare to database transactions, and/or other technologies to minimize the amount of data transferred. On Fri, Feb 14, 2014 at 4:05 PM, Scott Moser wrote: > On Thu, 13 Feb 2014, Scott Ritchie wrote: > >> On Thu, Feb 13, 2014 at 9:42 PM, Scott Moser wrote: >> > I really think that 98% of all people who would possibly touch a amd64 >> > server ISO will never install a i386 package. >> > >> >> That's probably accurate, however most server users fit into some >> different 2% bucket. 98% don't need Tomcat either, but breaking that >> would be really bad. > > I certainly would not suggest we install tomcat on people's systems by > default. The default we have caters to the 2% at the cost of the 98. > > -- > 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
Re: remove i386 from foreign arch on server install?
On Sat, Feb 15, 2014 at 10:56:36PM -0700, Adam Conrad wrote: > > It actually explicitly does the inverse right now, only twiddles > foreign arch on install, not upgrade, assuming that you know what > you're doing if you turn it off. Well, okay, new installs and upgrades from pre-oneiric. I guess I can ditch that part of the code now. :P ... Adam -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Sat, Feb 15, 2014 at 02:58:25PM +, Colin Watson wrote: > > A much better option would be to tweak the existing apt-setup/multiarch > preseed for server vs. desktop installs. (I don't remember whether this > would remove an architecture that dpkg.postinst has already added, but > it could; alternatively, we could reasonably make dpkg.postinst only do > its thing for upgrades rather than new installs, with s/lt/lt-nl/ or > similar.) It actually explicitly does the inverse right now, only twiddles foreign arch on install, not upgrade, assuming that you know what you're doing if you turn it off. The problem with moving this functionality into an installer is that *all* installers need to grow the functionality, and if you sort out a way to install without one of our blessed installers, you get a weirdly-different system. ... Adam -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Sat, Feb 15, 2014 at 02:56:13PM +, Colin Watson wrote: > On Fri, Feb 14, 2014 at 02:19:10PM +, Robie Basak wrote: > > On Fri, Feb 14, 2014 at 09:03:17AM -0500, Scott Moser wrote: > > > Fair. However, the 40M of space *is* permanent waste. > > > > In addition, we're promoting doing things in containers more and more - > > particularly in server deployments. The 40M gets multiplied by the > > number of containers you have on a system. And currently, we end up > > fetching this for each container, too. > > These are separate problems; there's no intrinsic reason why the > defaults for a container should have to be the same as the defaults on a > bare-metal installation. In fact, given how LXC templates work, if they > are the same it's because somebody made an explicit choice to that > effect. It's indeed an explicit choice. Since 12.04, we've tried very hard to keep our templates as close to a standard install as possible. Someone should be able to copy an existing Ubuntu system into a container or copy a container rootfs onto a real machine and both should work exactly as expected (well, except for you needing to install a kernel and bootloader in the second case, obviously). We expect anyone following software installation instructions to be able to use those identically on a standard install or in a container. Dropping i386 by default in containers would break that. Note also that a lot of users are using containers specifically to contain proprietary software they don't trust and those are very often i386 multi-arch packages, so the i386 on amd64 use case in container is a fairly common one. (If our main concern here is JuJu and the way it deploy services, it may be worth having JuJu just customize its image using cloud-init userdata or similar to turn off i386 if it won't need it, but I'd be opposed to doing this by default unless it's a project wide change.) -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Fri, Feb 14, 2014 at 02:35:55AM +, Dimitri John Ledkov wrote: > How about, starting to arch qualify sources lists? It's an interesting idea, but it would have some very weird effects for adding PPAs or other archives, because the defaults would then result in lots of uninstallable i386 packages in cache for systems without [arch=i386] for the primary archive. We could change add-apt-repository, but a lot of instructions just have people editing sources.list directly. Seems like a lot of potential trouble. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Thu, Feb 13, 2014 at 02:26:27PM -0700, Adam Conrad wrote: > 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. A much better option would be to tweak the existing apt-setup/multiarch preseed for server vs. desktop installs. (I don't remember whether this would remove an architecture that dpkg.postinst has already added, but it could; alternatively, we could reasonably make dpkg.postinst only do its thing for upgrades rather than new installs, with s/lt/lt-nl/ or similar.) -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Fri, Feb 14, 2014 at 02:19:10PM +, Robie Basak wrote: > On Fri, Feb 14, 2014 at 09:03:17AM -0500, Scott Moser wrote: > > Fair. However, the 40M of space *is* permanent waste. > > In addition, we're promoting doing things in containers more and more - > particularly in server deployments. The 40M gets multiplied by the > number of containers you have on a system. And currently, we end up > fetching this for each container, too. These are separate problems; there's no intrinsic reason why the defaults for a container should have to be the same as the defaults on a bare-metal installation. In fact, given how LXC templates work, if they are the same it's because somebody made an explicit choice to that effect. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Thu, Feb 13, 2014 at 10:23:25PM -0800, Scott Ritchie wrote: > > Perhaps we should instead assess why apt needs to spend so much time > and bandwidth checking for updates. Other devices with frequent > updates (eg mobile phones) don't have to download nearly as much data To be fair, the impact of this is most often seen on development releases, where the Packages files change every 15-30 minutes, which gives developers a skewed view of how it works for everyone else. On a stable release, you generate hits to a mirror for the release pocket, but you never actually redownload Packages, so the impact is limited to downloading the post-release (updates/security) pocket indexes for two arches, which is a much smaller hit. ... Adam -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Fri, Feb 14, 2014 at 09:03:17AM -0500, Scott Moser wrote: > Fair. However, the 40M of space *is* permanent waste. In addition, we're promoting doing things in containers more and more - particularly in server deployments. The 40M gets multiplied by the number of containers you have on a system. And currently, we end up fetching this for each container, too. Caches can mitigate this, but so can just not doing it in the first place. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Thu, 13 Feb 2014, Scott Ritchie wrote: > On Thu, Feb 13, 2014 at 9:42 PM, Scott Moser wrote: > > I really think that 98% of all people who would possibly touch a amd64 > > server ISO will never install a i386 package. > > > > That's probably accurate, however most server users fit into some > different 2% bucket. 98% don't need Tomcat either, but breaking that > would be really bad. I certainly would not suggest we install tomcat on people's systems by default. The default we have caters to the 2% at the cost of the 98. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Fri, 14 Feb 2014, Iain Lane wrote: > On Fri, Feb 14, 2014 at 12:42:09AM -0500, Scott Moser wrote: > > On Thu, 13 Feb 2014, Scott Ritchie wrote: > > […] > > I personally think its an extremely high cost bandwidth cost spread across > > Canonical, other mirror providers and the end user to account for a very > > rare case where someone would want to do this. > > > > That fresh install I just did, when I type 'apt-get update' (after rm -Rf > > /var/lib/dpkg/lists), apt tells me: > > with i386 enabled: > > Fetched 27.6 MB in 16s (1,655 kB/s) > > du /var/lib/apt/lists: 133M > > without i386 enabled: > > Fetched 20.2 MB in 11s (1,687 kB/s) > > > > du /var/lib/apt/lists: 94M > > > > So 40M of space and 7M of network traffic and 5 seconds of time (having > > hit a local proxy). > > This analysis is misleading, because the release pocket (the big one) > doesn't change for stable releases. Downloading all of that data isn't > something which is done all of the time for every user. Fair. However, the 40M of space *is* permanent waste. And HEAD'ing *is* done all the time for every user, and -updates and -proposed change frequently. It is real cost, and I'm suggesting it comes at very little gain. To see that cost, using a local caching proxy, I did repeated 'apt-get update' with and without i386 in the foreign arch list. The *best* case scenario I saw (local proxy all of this cached) was real time of 7.5 seconds for without, and 9.5 seconds with. It is inarguable that there is cost. Ignoring source debs, it is exactly a doubling of the number of http requests. No one seems to be suggesting they install lots of i386 packages on their amd64 server systems. (Remember, this wasn't even *possible* 30 months ago). -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Thu, Feb 13, 2014 at 10:23 PM, Scott Ritchie wrote: > Perhaps we should instead assess why apt needs to spend so much time > and bandwidth checking for updates. Other devices with frequent > updates (eg mobile phones) don't have to download nearly as much data > -- surely apt could be a bit smarter. To expand on this, I did some preliminary investigation of the current Trusty universe Packages file for i386 and amd64. All of the architecture: all packages occur identically in both the i386 and amd64 files. Original (compressed.bz2) file size for both: 5.7M + 5.7M = 11.4M Combining them and removing the duplicate arch: all packages and recompressing: 8.9 M So we can trivially save 15% by just merging the two files together! Parser code at https://gist.github.com/YokoZar/8999726 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Fri, Feb 14, 2014 at 12:42:09AM -0500, Scott Moser wrote: > On Thu, 13 Feb 2014, Scott Ritchie wrote: > […] > I personally think its an extremely high cost bandwidth cost spread across > Canonical, other mirror providers and the end user to account for a very > rare case where someone would want to do this. > > That fresh install I just did, when I type 'apt-get update' (after rm -Rf > /var/lib/dpkg/lists), apt tells me: > with i386 enabled: > Fetched 27.6 MB in 16s (1,655 kB/s) > du /var/lib/apt/lists: 133M > without i386 enabled: > Fetched 20.2 MB in 11s (1,687 kB/s) > > du /var/lib/apt/lists: 94M > > So 40M of space and 7M of network traffic and 5 seconds of time (having > hit a local proxy). This analysis is misleading, because the release pocket (the big one) doesn't change for stable releases. Downloading all of that data isn't something which is done all of the time for every user. -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Fri, Feb 14, 2014, Scott Moser wrote: > So 40M of space and 7M of network traffic and 5 seconds of time (having > hit a local proxy). It strikes me that 95% of the contents of packages files are identical between i386 and amd64, so download and storage ought to be made much smaller; this probably needs non-trivial APT work though. This would be a nice saving for both desktop and server users and would avoid the question of the cost of keeping i386 enabled on amd64 installs. -- Loïc Minier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Thu, Feb 13, 2014 at 9:42 PM, Scott Moser wrote: > I really think that 98% of all people who would possibly touch a amd64 > server ISO will never install a i386 package. > That's probably accurate, however most server users fit into some different 2% bucket. 98% don't need Tomcat either, but breaking that would be really bad. Perhaps we should instead assess why apt needs to spend so much time and bandwidth checking for updates. Other devices with frequent updates (eg mobile phones) don't have to download nearly as much data -- surely apt could be a bit smarter. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Thu, 13 Feb 2014, Scott Ritchie wrote: > 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. It is disabled in cloud-images for quite some time. (I think 12.10). I personally think its an extremely high cost bandwidth cost spread across Canonical, other mirror providers and the end user to account for a very rare case where someone would want to do this. That fresh install I just did, when I type 'apt-get update' (after rm -Rf /var/lib/dpkg/lists), apt tells me: with i386 enabled: Fetched 27.6 MB in 16s (1,655 kB/s) du /var/lib/apt/lists: 133M without i386 enabled: Fetched 20.2 MB in 11s (1,687 kB/s) du /var/lib/apt/lists: 94M So 40M of space and 7M of network traffic and 5 seconds of time (having hit a local proxy). I really think that 98% of all people who would possibly touch a amd64 server ISO will never install a i386 package. > > On Thu, Feb 13, 2014 at 1:26 PM, Adam Conrad 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
Re: remove i386 from foreign arch on server install?
On 13 February 2014 11:24, Scott Moser wrote: > Hey all, > 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 > > 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. > > What do people think about removing this? > Does anyone have a use case where this is important, and is not easily > worked around just by doing: > sudo dpkg --add-architecture i386 > I'd like to see i386 to still be enabled in dpkg by default on amd64. However, I do agree that it is undesirable side-effect of downloading apt-metadata for packages one might not install on a given machine. Disabling i386 on dpkg level, does not bring us closer to be able eventually in the future more amd64 from primary mirrors, to ports mirrors. How about, starting to arch qualify sources lists? Cause what I think you really want on the server is this: deb [arch=amd64] http://archive.ubuntu.com/ubuntu trusty main universe multiverse restricted deb-src http://archive.ubuntu.com/ubuntu trusty main universe multiverse restricted On the desktop (one can also use [arch=i386,amd64] instead of doing one line per arch): deb [arch=i386] http://archive.ubuntu.com/ubuntu trusty main universe multiverse restricted deb [arch=amd64] http://archive.ubuntu.com/ubuntu trusty main universe multiverse restricted deb-src http://archive.ubuntu.com/ubuntu trusty main universe multiverse restricted On a developer machine: deb [arch=i386,amd64] http://archive.ubuntu.com/ubuntu trusty main universe multiverse restricted deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports trusty main universe multiverse restricted deb-src http://archive.ubuntu.com/ubuntu trusty main universe multiverse restricted The case for multiarch by default (in dpkg-only) on the server is easy trail for sys-admin to find: installing _i386, argh apt says missing packages, check apt sources, AHA i need i386 repository added. Boom everything works. vs zero hints that both architecture and repositories need to be enabled. The case for multiarch by default (both dpkg and apt-sources) on the desktop is: Steam, Skype, Wine, etc. The case for multiarch by default (armhf is self configured in sources - undecided if it should be enabled in dpkg by default) on the developer machine: is cross-compilation to mobile/embedded, and/or multilib compilation to 32-bit. -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On 14 February 2014 00:24, Scott Moser wrote: > Hey all, > 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 > > 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. > > What do people think about removing this? > Does anyone have a use case where this is important, and is not easily > worked around just by doing: > sudo dpkg --add-architecture i386 I'm very much in favour of removing it, specifically for cloud images, but ideally all servers. Yes, it's something that needs some guidance for enabling, but its half as many index files to download, and half the size local mirror to maintain. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Thu, Feb 13, 2014 at 4:32 PM, Adam Conrad wrote: > On Thu, Feb 13, 2014 at 03:57:21PM -0800, Scott Ritchie wrote: >> 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. > > I assume those are precise users, where the installed did the magic > conffile hack, since everything post-precise does it, like I said, in > the dpkg postinst. > I believe it's also people using installs upgraded from Precise. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Thu, Feb 13, 2014 at 05:32:18PM -0700, Adam Conrad wrote: > > I assume those are precise users, where the installed did the magic ^ installer > conffile hack, since everything post-precise does it, like I said, in > the dpkg postinst. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
On Thu, Feb 13, 2014 at 03:57:21PM -0800, Scott Ritchie wrote: > 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. I assume those are precise users, where the installed did the magic conffile hack, since everything post-precise does it, like I said, in the dpkg postinst. ... Adam -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: remove i386 from foreign arch on server install?
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 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
Re: remove i386 from foreign arch on server install?
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
