Re: [ptxdist] [RFC PATCH] doc: Add section on creating new layers

[Michael Olbrich <m.olbrich@pengutronix.de>]

Hi,

On Tue, Sep 03, 2019 at 08:49:12PM +0200, Alexander Dahl wrote:
> I tried a little more:
> 
>     mkdir DistroKit-rpi1
>     cd DistroKit-rpi1
>     ln -s ../DistroKit base
> 
> The new layer is almost empty so far, see below.
> 
> On Tue, Sep 03, 2019 at 04:22:55PM +0200, Michael Olbrich wrote:
> > On Tue, Sep 03, 2019 at 03:48:17PM +0200, Alexander Dahl wrote:
> > > Am Dienstag, 3. September 2019, 15:08:08 CEST schrieb Michael Olbrich:
> > > > If there is just on platform, then ptxdist will just use that on if no
> > > > selected_platformconfig exists. This is especially useful with layers,
> > > > because it will then just pick the config from the first layer that has
> > > > one.
> > > 
> > > So this is not different to ptxdist behaviour without layers. Maybe DistroKit 
> > > is no good example, because it contains more than one platform and you must 
> > > select one to get going?
> > 
> > Correct. You need to select one (or run ptxdist with --platformconfig=...).
> > Once ptxdist has crated a platformconfig for the new layer, you need to
> > select that one. PTXdist will complain if you forget this step.
> 
> Indeed! Because there was no platformconfig in my new layer, I
> selected the platformconfig from the base layer:
> 
>     ptxdist platform base/configs/platform-rpi/platformconfig
> 
> > > > It does not touch the selected_* links you might need to change those if it
> > > > happens.
> > > 
> > > So the question remains. If there is more than one platform or config, where 
> > > should it be selected best and how?
> > 
> > Only selections in the current layer are used. Anything else is ignored.
> > And PTXdist enforces that the selected config is from the top layer (if the
> > config exists there) or the next layer that contains it.
> 
> "Enforces" does not mean it changes the platfrom selection by itself
> automatically, but just checks and bails out in case. For example,
> after selecting the platformconfig in the base layer before, I changed
> something in the platformconfig, which leads to ptxdist creating a
> platformconfig file in my new layer. Now ptxdist stops like this:
> 
> 
>     alex@lemmy ~/src/DistroKit-rpi1 % p -q -j6 go
> 
>     ptxdist: error: The selected config file:
>     ptxdist: error:
>     DistroKit-rpi1/base/configs/platform-rpi/platformconfig
>     ptxdist: error: is overwritten by:
>     ptxdist: error: DistroKit-rpi1/configs/platform-rpi/platformconfig
>     ptxdist: error: The config file in the outer layer must be used!
> 
>     error: error during generation of dependencies
> 
> 
>     ptxdist: error: error in dgen
> 
> 
> The error message is clear, I have to select the platform in my upper
> layer now. Okay, did that.
> 
> Now I changed something in my platformconfig to make it equal to the
> platformconfig of the lower layer again. This leads to ptxdist
> removing the platformconfig from the upper layer (just keeping
> platformconfig.old), I have a symlink 'selected_platform' to a non
> existent file and ptxdist bails out like this:
> 
> 
>     alex@lemmy ~/src/DistroKit-rpi1 % p -q -j6 go                                   
>     error:  'selected_platformconfig' is missing
>             try 'ptxdist platform <platformconfig>'
> 
> 
> All in all, one has to take care a little and reset the selected
> platform if ptxdist complains, but ptxdist either seems to build or
> print what's wrong, so it's not that hard to find out, which platform
> to select.

Right, this error message could be a bit better. We should handle existing
symlinks that point to non-existing paths differently.

So, I've considered handling this automatically when the config is created
or deleted. However, the code handling this stuff is quite complex, with
all the different possibilities when it comes to symlinks. I still need to
track down why things happen differently for Roland :-/. So I'm reluctant
to add more complexity and change the links automatically.

And I don't want to magically use a file other and the one the link points
to (e.g. use configs/ptxconfig when the link points to
base/configs/ptxconfig). Someone might open the file directly and things
get confusing.

But maybe we could accept --ptxconfig=configs/ptxconfig as a command-line
option, even if only base/configs/ptxconfig exists (and the same for the
platformconfig of course). Would that make sense to you?

> I'll see what I can do with that information, to improve the
> documentation or the patch, if nobody else wants to jump in.

Please do so. I'll be happy to review the result.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de