I'll give it a shot and try to sum up the current state of affairs in
this discussion. In accordance to the "Package managers all the way
down"-presentation, I'm gonna use the term LPM (for language package
manager) for now on.
*Requirements*
- repeatable and verifyable licensing of all dependencies that a LPM
pulls in.
- locking down specific versions of packages and their dependencies for
reproductible builds.
*Optionals*
- strict separation of fetch, compile, install stages. If a specifc LPM
requires it, those might be intermingled or left out [Mark]
- opaque packaging: similar to static linking, we should at least have a
way to bundle up a complete application into a single package. Maybe it
might even be the default (like rust does it at the moment).
- leverage as much as possible of the functionality the LPMs provide
instead of reimplementing it.
*Wish List*
- separating out the LPM infrastructure into one or more distinct
layers, not treating it as OE/bitbake core functionality. [Paul]
- support for the use of multiple languages/LPMs inside a single recipe,
hopefully even package. [myself]
*Proposed Solutions*
- having lockdown files shipped with the recipes (in whatever form to be
defined)
- leveraging the recipe system to resolve licensing.
If we can boil things down to the common set that we all expect, it will
in my opnion serve as a blueprint for the actual implementation to follow.
Greetz,
--
Josef Holzmayr
Software Developer Embedded Systems
Tel: +49 8444 9204-48
Fax: +49 8444 9204-50
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548
_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
