Re: [ptxdist] ptxdist initial impressions

[Ladislav Michl <oss-lists@triops.cz>]

Hi there,

On Wed, May 24, 2023 at 12:34:21PM +0200, Alexander Dahl wrote:
> Hello Jookia,
> 
> as a long term user not affiliated with pengutronix I have some comments which 
> might help.  See below.
> 
> Am Mittwoch, 17. Mai 2023, 18:11:31 CEST schrieb Jookia:
> > Hello ptxdist friends,
> > 
> > I spent some time over the past few days trying to use ptxdist and
> > documenting all the pain I hit in the process. This isn't a criticism
> > more just anecdotal data of my experience. Hopefully it's useful to
> > smooth down some rough edges.
> > 
> > I'm going to write this up in a psuedo-markdown format in sections,
> > sorry if that breaks anyone's workflow.
> > 
> > 
> > Documentation
> > -------------
> > 
> > First up: Documentation is quite good aside from the 'Getting a working
> > environment' section. I will be focusing on this today since I think it's
> > probably the most critical problem with ptxdist at the moment: I expect
> > that by the end of following this chapter I should have a bootable image
> > of some kind and commands for using it, such as with qemu.
> > 
> > The first issue is that I'm told to downloaded files, but I'm not linked
> > to them, quoting:
> > 
> > ptxdist-2023.05.0.tar.bz2
> > OSELAS.BSP-Pengutronix-Example.tar.bz2 (or a similar source)
> > ptxdist-2019.09.0.tar.bz2
> > OSELAS.Toolchain-2019.09.1.tar.bz2
> > 
> > The OSELAS website is linked as ptxdist.org that doesn't mention OSELAS
> > at all. There is a link to the toolchain but it's a different version.
> > I managed to find a BSP for 'Generic' but it's 9 years old.
> 
> +1
> 
> That has to be improved.  There's no easy accessible single platform example 
> BSP to get your feet wet, and DistroKit is nice for supporting some quite 
> common SBCs, but is already quite complicated.

would something like this be sufficient?

diff --git a/doc/environment.rst b/doc/environment.rst
index 18aecec4e..670f86a48 100644
--- a/doc/environment.rst
+++ b/doc/environment.rst
@@ -17,10 +17,13 @@ components which are available to the public).
 In order to build |ptxdistBSPName|, the following source archives have to be available
 on the development host:
 
- * ptxdist-|ptxdistVendorVersion|.tar.bz2
+ * `ptxdist-|ptxdistVendorVersion|.tar.bz2 <https://public.pengutronix.de/software/ptxdist/ptxdist-|ptxdistVendorVersion|.tar.bz2>`_
  * |ptxdistBSPName|.tar.bz2 (or a similar source)
- * ptxdist-|oselasTCNVendorptxdistversion|.tar.bz2
- * OSELAS.Toolchain-|oselasTCNVendorVersion|.tar.bz2
+
+Additionally, those source archives are needed to build toolchain:
+
+ * `OSELAS.Toolchain-|oselasTCNVendorVersion|.tar.bz2 <https://public.pengutronix.de/oselas/toolchain/OSELAS.Toolchain-|oselasTCNVendorVersion|.tar.bz2>`_
+ * `ptxdist-|oselasTCNVendorptxdistversion|.tar.bz2 <https://public.pengutronix.de/software/ptxdist/ptxdist-|oselasTCNVendorptxdistversion|.tar.bz2>`_
 
 Main Parts of PTXdist
 ~~~~~~~~~~~~~~~~~~~~~

> What's also lacking: some template or documentation on how to start from 
> scratch without deriving your work from pre existing BSPs.  I tried that 
> lately and put the steps online:
> 
> https://gist.github.com/LeSpocky/31af75ab63bc6f35fd71d53f06b5a50e
> 
> I dropped that link in IRC, but I got no clear signal if that's something to 
> put into the official ptxdist documentation?

I'm hereby sending a clear signal to maintainers that I'd like to
see something like that in the documentation ;-)

> > The documentation says having a BSP is optional, but there's no
> > instructions on how to work without one. It's probably not even a good
> > idea to mention this, perhaps ptxdist should provide a skeleton project?
> > 
> > I get the distinct impression the right solution here is to use
> > DistroKit as the starter BSP. This isn't mentioned anywhere in the
> > documentation but is something I found out about on IRC.
> > 
> > I'm also not a fan of suggesting installing ptxdist. It seems strange to
> > lock yourself to a repository of packages that you will need to tweak
> > and fix. I would like to see more support for running it in tree.
> 
> Maybe this is some kind of misunderstanding.  You would never touch the 
> distributed/installed ptxdist, but "overwrite" things by placing package rules 
> with the same name in your BSP.  For example if you need a version bump for 
> libfoo, you could copy /usr/local/lib/ptxdist-2100.01.0/rules/libfoo.make to 
> your BSP at rules/libfoo.make and adapt it to your needs.

or you can even put that into post/ rules in case just upgrading
package is sufficient (no configure, etc. changes)