Robert Schwebel wrote:
> On Fri, Oct 20, 2006 at 06:30:05PM +0200, Jan Kiszka wrote:
>> What I mean with this are -maybe- only menu skins to customize PTXdist
>> in a way that users who don't know if they need "minimal logrotate" or
>> busybox with or without chroot are able to install target images from
>> pre-built binary packages.
>
> This is something which is on my radar for quite some time now, but I
> don't had the time to think about it in more detail.
>
>> This would mean to reduce some menu options drastically, but also to
>> add new, special options ("install demo scripts+configs -> Erika robot
>> driving along the hall" ;)).
>
> Note that customizing menues from a BSP is possible today.Some pointers on this (for poor Christoph who has^H^H^Hwants to do the work :))? > >> And it would require to have those pre-built packages for the >> installing host, not on the target. That's something I still don't >> understand, if your ipkg is for installing packages from within the >> running target (would sound like the SLIND approach) or if those >> packages can be used by the host to prepare e.g. a CF-card image (like >> we do here every day). >> >> Once this feature became real, our LiRE would be a very, very small >> configuration + collection of in-house packages for PTXdist. > > At the moment the ipkg packages are only binary packets of the files for > the target side, no development files involved. Ok. That would already be a problem for us, because our industry partners and our students develop within a robotic framework that builds against various special libs. > > What I'd like to see in PTXdist is something which is known under the > label PTXDIST_PATH within Pengutronix. The idea would be to have a > PTXDIST_PATH environment variable or something like this, pointing to a > location where pre-built binary packets (host+target part) are stored. > > This would make it possible to do work in a "layered" way. For example, > a common scenario in our customer projects is that > > a) Pengutronix develops a BSP for a module > b) The module vendor adds his own stuff > c) The end user adds his application. > > So if you are for example c), it would mean that, if somewhere in > PTXDIST_PATH there is a pre-built glibc packet found, it is simply > installed instead of being built from the sources. Only the local > applications, being added by the end user himself, are being built from > the sources. That sounds perfect. > > I've once hacked a prototype, using one of these LD_PRELOAD tools that > can be used to do on-the-fly packaging of "make install" stages. It > turned out that this has some drawbacks: > > - You don't catch if some upstream parts have to be recompiled due to > confiuration changes. > > - It didn't work properly for all packets. > > - I've no good idea how to solve the case where somebody wants to > recompile a packet by intention. > > Seen from the configuration side, we could introduce [*] and [M] for the > variants "recompile" vs. "take from packets". > > It needs more thinking, so if you come up with a good idea I'm all ears. I think we first need to analyse the PTXdist-way of building and installing things more thoroughly. Also, this part is not top-most on our list. The migration path includes an intermediate step to keep our installation infrastructure over a PTXdist build system. Nevertheless, we will always keep this goal in mind and may come back with more concrete questions/ideas. Jan
signature.asc
Description: OpenPGP digital signature
-- ptxdist mailing list [email protected]
