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.
> 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.
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.
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.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
--
ptxdist mailing list
[email protected]
