All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Holzmayr <holzmayr@rsi-elektrotechnik.de>
To: Alexander Kanavin <alexander.kanavin@linux.intel.com>,
	openembedded-architecture@lists.openembedded.org,
	Yocto Project <yocto@yoctoproject.org>
Subject: Re: [Openembedded-architecture] Sum up - Proposal: dealing with language-specific build tools/dependency management tools
Date: Thu, 16 Mar 2017 09:17:57 +0100	[thread overview]
Message-ID: <83c550f8-9f33-3179-3092-19fad4a37aec@rsi-elektrotechnik.de> (raw)
In-Reply-To: <37d4f98c-9102-f4bf-c6cc-f64e1ffbce40@linux.intel.com>

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



  parent reply	other threads:[~2017-03-16  8:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-10 13:49 Proposal: dealing with language-specific build tools/dependency management tools Alexander Kanavin
2017-03-10 14:30 ` [Openembedded-architecture] " Otavio Salvador
2017-03-10 14:48   ` Alexander Kanavin
2017-03-10 14:58     ` Otavio Salvador
2017-03-10 15:10       ` Alexander Kanavin
2017-03-10 15:33         ` Derek Straka
2017-03-10 15:35         ` Derek Straka
2017-03-13  8:25         ` Piotr Figiel
2017-03-13 17:51         ` Bruce, Henry
2017-03-16 10:25           ` Alexander Kanavin
2017-03-10 16:23       ` Mark Hatle
2017-03-10 20:37       ` Josef Holzmayr
2017-03-10 20:49 ` Trevor Woerner
2017-03-11 13:07   ` Josef Holzmayr
2017-03-13 20:58 ` Paul Eggleton
2017-03-16  8:17 ` Josef Holzmayr [this message]
2017-03-16  9:30   ` [Openembedded-architecture] Sum up - " Paul Barker
2017-03-16 10:35     ` Alexander Kanavin
2017-03-16 10:48       ` Jack Mitchell
2017-03-16 11:42         ` Alexander Kanavin
2017-03-16 11:47           ` Alexander Kanavin
2017-03-16 19:41         ` Patrick Ohly
2017-03-16 15:45       ` Mark Hatle
2017-03-16 15:43     ` Mark Hatle
2017-03-16 10:21   ` Alexander Kanavin

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=83c550f8-9f33-3179-3092-19fad4a37aec@rsi-elektrotechnik.de \
    --to=holzmayr@rsi-elektrotechnik.de \
    --cc=alexander.kanavin@linux.intel.com \
    --cc=openembedded-architecture@lists.openembedded.org \
    --cc=yocto@yoctoproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.