mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Alexander Dahl <post@lespocky.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] [RFC PATCH] doc: Add section on creating new layers
Date: Tue, 3 Sep 2019 20:49:12 +0200	[thread overview]
Message-ID: <20190903184911.36dxo6xv7covqf6d@falbala.home.lespocky.de> (raw)
In-Reply-To: <20190903142255.hxisijxauvyb46b7@pengutronix.de>


[-- Attachment #1.1: Type: text/plain, Size: 3759 bytes --]

Hello Michael,

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.

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

Greets
Alex

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN     | speech censured, the first thought forbidden, the
 X  AGAINST      | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 92 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

  reply	other threads:[~2019-09-03 18:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03 11:50 Alexander Dahl
2019-09-03 12:00 ` Roland Hieber
2019-09-03 12:22   ` Alexander Dahl
2019-09-03 13:08     ` Michael Olbrich
2019-09-03 13:38       ` Roland Hieber
2019-09-03 14:12         ` Michael Olbrich
2019-09-04 10:30           ` Roland Hieber
2019-09-04 12:55             ` Roland Hieber
2019-09-03 13:48       ` Alexander Dahl
2019-09-03 14:22         ` Michael Olbrich
2019-09-03 18:49           ` Alexander Dahl [this message]
2019-09-04  5:37             ` Michael Olbrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190903184911.36dxo6xv7covqf6d@falbala.home.lespocky.de \
    --to=post@lespocky.de \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox