On 01/06/2017 07:33 AM, Jonathan Wakely wrote:
On 05/01/17 14:42 -0500, Randy Barlow wrote:
> On Thu, 2017-01-05 at 17:02 +0000, Jonathan Wakely wrote:
>> Which definitely changes how software is built.
>
> Containers also change the way software must be written in some cases,
> since they expect there to be one main process and don't expect that
> main process to interact with other "main" processes on the system.
> There are some program architectures that aren't well suited to be run
> in containers since containers expect programs to work in specific
> ways. I don't think they are general enough to cover all use cases.
>
> I also expect that users will not appreciate being forced to use
> containers if they want to keep being able to do things they can do
> today. Offering it to them as an option rather than the only solution
> is probably a friendlier approach.
That would certainly be a problem if the proposal was to run each
32-bit application in its own container environment, but I think the
suggestion is to have a single 32-bit container used by all 32-bit
software. With that approach all the 32-bit software would be able to
interact with the rest of the 32-bit system, there wouldn't be
segregation between them.
Yes, I was unclear about this, but that was where I was going with it. A single
32-bit container whose purpose was to share the 32-bit runtime. That being said,
the counter-proposal of figuring out how to keep the layout the same as today
but keeping the content in separate repositories is compelling and I'm
investigating that further.
But we would need to consider how a 32-bit application starts other
programs via things like xdg-open. Would you have to have a 32-bit
browser installed so that you could click on links in 32-bit
applications? Would xdg-utils have to be installed on the system
twice, once in the 64-bit host and once in the 32-bit container? And
install things like Firefox and image viewers twice?
Very good questions and I don't have all the answers right now, but again, I
think the "separate repository" solution might be closer, as the end result
should keep things in the same hierarchy.