dev_install for general UNIX use cases?

[Trever]

Hi,

Theoretically it would seem, if the emerge binaries were built and hosted along with what's out there now, dev_install could be used to emerge *NIX userland binaries generally, not just the current handful of binaries that are primarily for Chrome OS dev/debugging.  There could be compilers, etc..

Could community members contribute such dev_install emerge binaries (not sure how those binaries get out there now), and if so, would they be accepted/hosted?  

I don't know the answer to that.

I presume that the use cases this question presupposes departs from the original use cases for dev_install, and the implications of what I'm asking are probably clear, but to be clear:  perhaps if this were allowed/possible, Chrome OS would develop it's own add-on Linux "distribution", installed per individual taste via dev_install.  Buy something off-the-shelf and keep the base OS with its verified boot security and auto updates from a well funded mother ship (Google), and add your own additional Linux userland as desired.  The former makes this unlike building and maintaining Chromium OS on generic hardware or installing a HEX build, etc., and the later makes this very unlike the way the average person who buys a Google Chrome OS device would be using it.

There's nothing to prevent such an add-on distro from happening by other means, and some chroot based efforts apparently already exist (eg. crouton), but using dev_install (which is already there on a stock device, and which Chrome OS developers presumably care about) and it's hosting might be more straightforward and well defined, depending on what's involved in contributing (if possible) to the pool of dev_install binaries out there now.  So that's why I'm asking.  Expanding the scope of dev_install is (at least naively) the most appealing possibility for the use case I'm imagining.

Thanks in advance,

Trever

[Mike Frysinger]

On Wed, Feb 20, 2013 at 4:03 PM, Trever <trr...@gmail.com> wrote:

Theoretically it would seem, if the emerge binaries were built and hosted along with what's out there now, dev_install could be used to emerge *NIX userland binaries generally, not just the current handful of binaries that are primarily for Chrome OS dev/debugging.  There could be compilers, etc..

long term, we want to get the compiler/C library as an installable package.  there's a few issues that need sorting out first though.

 

Could community members contribute such dev_install emerge binaries (not sure how those binaries get out there now), and if so, would they be accepted/hosted?  

yes & no

[hard] no: we aren't going to accept random .tbz2 packages from people.

yes: submit an ebuild (ideally pulled from upstream Gentoo) to the portage-stable overlay, then add it to the chromeos-dev package.

maybe: depending on the request, i'm not sure chromeos-dev will scale as we want because that controls all packages that go into a "dev" image.  we might have to introduce a chromeos-dev-install package which our builders would use to seed the dev-installer repo.

maybe (part 2): crap ebuilds are crap ebuilds and we don't want to support those :).

 

I presume that the use cases this question presupposes departs from the original use cases for dev_install, and the implications of what I'm asking are probably clear, but to be clear:  perhaps if this were allowed/possible, Chrome OS would develop it's own add-on Linux "distribution", installed per individual taste via dev_install.  Buy something off-the-shelf and keep the base OS with its verified boot security and auto updates from a well funded mother ship (Google), and add your own additional Linux userland as desired.  The former makes this unlike building and maintaining Chromium OS on generic hardware or installing a HEX build, etc., and the later makes this very unlike the way the average person who buys a Google Chrome OS device would be using it.

we'd like to have a script that we ship that allows for easily managing secondary distros.  unfortunately, we haven't had anyone step up just yet to implement this :).  note: i'm not talking about scripts tailored for specific distributions -- we want a framework so that any random distro lover out there can add their own in w/out having to duplicate all the CrOS-specific pieces.

-mike 

[Trever]

On Wednesday, February 20, 2013 1:09:05 PM UTC-8, Mike Frysinger wrote: 

Could community members contribute such dev_install emerge binaries (not sure how those binaries get out there now), and if so, would they be accepted/hosted?  

yes & no

[hard] no: we aren't going to accept random .tbz2 packages from people.

yes: submit an ebuild (ideally pulled from upstream Gentoo) to the portage-stable overlay, then add it to the chromeos-dev package.

maybe: depending on the request, i'm not sure chromeos-dev will scale as we want because that controls all packages that go into a "dev" image.  we might have to introduce a chromeos-dev-install package which our builders would use to seed the dev-installer repo.

maybe (part 2): crap ebuilds are crap ebuilds and we don't want to support those :).

The trust, quality, and scaling issues are of course understandable.   Let me look further at some of the things you reference here before possibly asking more questions.  It sounds like there's some room here to have at least some things accepted.

 

 

I presume that the use cases this question presupposes departs from the original use cases for dev_install, and the implications of what I'm asking are probably clear, but to be clear:  perhaps if this were allowed/possible, Chrome OS would develop it's own add-on Linux "distribution", installed per individual taste via dev_install.  Buy something off-the-shelf and keep the base OS with its verified boot security and auto updates from a well funded mother ship (Google), and add your own additional Linux userland as desired.  The former makes this unlike building and maintaining Chromium OS on generic hardware or installing a HEX build, etc., and the later makes this very unlike the way the average person who buys a Google Chrome OS device would be using it.

we'd like to have a script that we ship that allows for easily managing secondary distros.  unfortunately, we haven't had anyone step up just yet to implement this :).  note: i'm not talking about scripts tailored for specific distributions -- we want a framework so that any random distro lover out there can add their own in w/out having to duplicate all the CrOS-specific pieces.

Not sure I understand the universality part of this.  Literally "any random" distro.... sounds impossible, no?  Can you say more about this idea?

Thanks,

Trever

[Mike Frysinger]

sure, at some point you've got to list a URL to a distro's install pkg or some other magic.  but the CrOS-specific pieces (managing the GPT table/etc...) are going to be the same for everyone.  we'd have a framework where you'd have a directory for each distro fragment.  e.g. we'd have "gentoo.sh" and "ubuntu.sh" and "fedora.sh" etc....  after the user has selected the distro from the available list, the common code would manage everything and call into the distro-specific fragments as need be ("download all necessary files", "bootstrap into XXX directory", "run post install hooks").

it's a crazy idea, but crazy is what i like :).

-mike

[Chris Sosa]

Agreed with Mike's points.

As another idea, developers could just host their own binhost.
Besides bootstrapping and packaging the chromeos-dev/test packages,
dev_install is just a small wrapper around emerge with a set binhost
that is based on the given version of the OS.

Part of the reason we chrome-dev/test are used, is that first, they
can bootstrap the system to a similar state that of Chromium OS
dev/test images (similar in that the rootfs remains unchanged). In
addition, we already know these packages "work" with ROOT=/usr/local.
Custom packages/ebuilds would also have to work running from the
stateful partition as the invariant dev-install should keep is that
the system continues to update and does not need recovery to go back
to non-dev mode.

-Sosa

> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>
>
>

[Trever]

On Wednesday, February 20, 2013 3:25:36 PM UTC-8, Chris Sosa wrote:

As another idea, developers could just host their own binhost. 

Another binhost is probably the next best thing.