Pmbootstrap: Split weston from postmarketos-base

[MartijnBraam]

I think the weston stuff should be split-off from postmarketos-base to another package since it's not a great Idea to provide the shell from the base package. This will give problems for any desktop shell based on weston in this case because of conflicting files (example: #184 )

Maybe postmarketos-weston

[craftyguy]

191 is somewhat related, since when weston splits off, it would be rather easy to take the code from post-install script that modifies weston.ini and put it into a post-install script in whatever package includes/configures weston.

[craftyguy]

Since weston IS a separate package already (with its own APKBUILD), what about adding a post-install script to weston's existing APKBUILD to handle device-specific configuration (or any additional configuration, like making a weston.ini) needed?

[MartijnBraam]

That means that we cannot use the upstream weston package and have to build it ourselves, that's why a wrapper package is better.

[WillemMali]

Why is building an issue? I'm willing to set up a build server as long as there's a place to host the artifacts from, I don't have enough bandwidth to serve artifacts at any significant scale.

[MartijnBraam]

The building is a issue, diverging packages from upstream is an issue when we don't have to.

[craftyguy]

a 'postmarketos-weston' package makes sense. Is the sole purpose of this package to 'configure' weston (e.g. provide weston.ini and populate it based on deviceinfo) ?

Are there any modifications that are made to the weston APKBUILD in aports that are different from the APKBUILD in upstream Alpine? If so, are there plans to reconcile those differences, either though upstreaming the modifications made in the pmos version, or rolling back the modifications in the pmos version to match Alpine's weston package?

[MartijnBraam]

The local weston version is for the patches that change the refresh rate and the red screen bug. This is in progress of being upstreamed to weston so that package can be removed from the pmbootstrap aports

[craftyguy]

I'm willing to take a stab at creating postmarketos-weston package (or maybe postmarketos-weston-config is a better name since this is really just configuring weston?).

Here are some requirements (and some open questions) I came up with based on the discussion here:

• I think all this technically will be is a APKBUILD which makes /etc/xdg/weston and a post-install script which essentially does #201.

• This package would have a dependency on weston.

• Would it need to include anything else at this point?

• The expectation as I understand it is that postmarketos-base (or any other package at this time) would NOT depend on this package, but device packages can include it if they want.

• What to call it?

Did I miss anything? @ollieparanoid, any thoughts too?

[ollieparanoid]

Sounds good with removing weston from postmarketos-base! How about postmarketos-ui-weston? Then we could easily filter the UI packages, if we make more of them and let the user choose in pmbootstrap init.

The profile script from postmarketos-base, which starts weston automatically, should also be moved in this package.

[craftyguy]

Just FYI, once #201 is complete / approved / merged, then I plan on working on this one, to remove weston from postmarketos-base and put it into a new package named postmarketos-ui-weston-config. The -config at the end of the name indicates that this package doesn't actually provide weston itself, but rather configures (and thus depends) on weston. @ollieparanoid @MartijnBraam , sound good?

[MartijnBraam]

I think it should just be postmarketos-ui-weston since it provides the "weston desktop environment", kinda like a metapackage. Especially if we make this a standard for other environments like postmarketos-ui-plasma postmarketos-ui-harmattan, none will actually contain anything except dependencies and config

[craftyguy]

Ok, yea that makes sense. postmarketos-ui-weston it is, unless there are any objections!

[craftyguy]

@MartijnBraam & @ollieparanoid

I have started to split this off, but I have a question about where to install Weston, and postmarketos-demos.

Currently Weston and the demos are installed regardless of what the user or device package say. I would like to resolve that. So there are three apparent (to me) options. When I mention Weston below, think Weston apps, etc, plus the config package I am building.

1. Weston and the demos are two separate options in the init, that users can opt to install

   • demos depend on weston
   • consider how other future meta packages are handled... this doesn't seem scalable

2. Device package(s) depends on Weston

   • device package dictates user experience, which may not be desirable (IMHO, this is not desirable )
   • existing behavior of pmos can be preserved

3. This Weston meta package is not selected or installed. Users have to explicitly install it with pmbootstrap install

   • 'default' install of pmos will be very bare, won't have Weston or demos
   • a future UI installer can offer Weston as an option

I prefer the 3rd option, since it results in separation of packages, and allows for a much larger number of future meta packages. Imagine 'init' with a half dozen (or more) options, and having to re-run init to change a choice.. maybe that is ok?

I'm totally open to feedback on which route y'all want to go with this, I'm trying to anticipate the future, and (nothing against the demos!) Pmos may have to move beyond running just the demos (and maybe weston) at some point :)

Sorry for typos, I am on mobile and have just one thumb functional right now :D

[ollieparanoid]

The first option is most closely to what I'd like to have. To be more precise, in my opinion I'd like to see:

• the user selects the UI in the init step (we parse the available postmarketos-ui packages and present them as list, just like with the device- packages)
• there should also be a none UI, that is just a console
• postmarketos-ui-weston has postmarketos-demos as dependency for now, so we don't need to ask this in a second step (and it only makes sense for weston anyway).

This way the users could still easily get some nice demos going (which is important I think, so they have something to play with after the installation and not just a blank weston screen).
And of course, demos had the purpose of being something to show off when introducing the project - they should become optional in the long run (but until we have something better to play with - like plasma mobile - I would keep them).

[craftyguy]

Ok, thanks for the prompt feedback, I will implement it as you suggested.

On July 21, 2017 11:52:01 PM PDT, Oliver Smith [e-mail] wrote:

The first option is most closely to what I'd like to have. To be more
precise:

• the user selects the UI in the init step (we parse the available
  postmarketos-ui packages and present them as list, just like with the
  device- packages)
• there should also be a none UI, that is just a console
• postmarketos-ui-weston has postmarketos-demos as dependency for
  now, so we don't need to ask this in a second step (and it only makes
  sense for weston anyway).

This way the users could still easily get some nice demos going (which
is important I think, so they have something to play with after the
installation and not just a blank weston screen).
And of course, demos had the purpose of being something to show off
when introducing the project - they should become optional in the long
run (but until we have something better to play with - like plasma
mobile - I would keep them).

--
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub:
https://github.com/postmarketOS/pmbootstrap/issues/190#issuecomment-317161261

[craftyguy]

@ollieparanoid @MartijnBraam

233 is my first attempt doing this. Please check that PR and provide feedback :)

[ollieparanoid]

Thanks for implementing this in #233 !