public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Alexander Smirnov <asmirnov@ilbers.de>
To: isar-users@googlegroups.com
Subject: Re: Reproducibility of builds
Date: Wed, 29 Nov 2017 21:53:04 +0300	[thread overview]
Message-ID: <c75334ef-75a7-1f34-df06-4dfe84112a64@ilbers.de> (raw)
In-Reply-To: <0508e061-441f-396b-98df-ab6226aa04cd@denx.de>

Hi everybody,

I've started working on this topic and here I'd like to share my vision. 
At the moment I've implemented simple PoC in my branch 'asmirnov/build_rep'.

What it does:

1. There is new recipe: base-apt. It provides task which:

  - Fetches packages from origin Debian apt to local folder using 
deboostrap.
  - Put these packages via 'reprepro' to local repository called 'base-apt'.

2. Buildchroot uses 'base-apt' to generate rootfs.

3. Isar image uses 'base-apt' and 'isar' repos to generate rootfs.



What are the key benefits of this approach:

1. Download session for upstream packages is performed in a single step.

2. You could use your local 'versioned' apt repository instead of 
downloading origin packages.

3. Having local apt repository managed by 'reprepro' provides us 
possibility to implement version pinning. Reprepro provides lots of 
things like:
  - Get package name.
  - Get package version.
  - Remove specific package from repo.
  - Add single package to repo.

So in general, if we have know which package version we want to have, we 
need to get binary with this version and put it to 'base-apt'.



Which issues I see at the moment:

1. The key issue for me the list of packages for 'base-apt'. So before 
'base-apt' task is executed, we should prepare full list of packages 
that will be used by:
  - buildchroot (BUILDCHROOT_PREINSTALL).
  - packages to build (their build deps).
  - image (IMAGE_PREINSTALL).

So I have an idea how to implement this via special tasks, will push 
patch for RFC, but if you have your own proposals, I'll be happy to 
discuss them!

Alex

  reply	other threads:[~2017-11-29 18:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-03  8:13 Claudius Heine
2017-08-21 11:23 ` Claudius Heine
2017-08-28 11:27   ` Claudius Heine
2017-09-05 10:05     ` Alexander Smirnov
2017-09-05 10:38       ` Jan Kiszka
2017-09-05 11:50         ` Alexander Smirnov
2017-09-05 11:54       ` Claudius Heine
2017-09-06 13:39         ` Claudius Heine
2017-09-18 15:05 ` Baurzhan Ismagulov
2017-09-19  8:55   ` Claudius Heine
2017-11-14 16:04 ` Christian Storm
2017-11-14 16:22   ` Claudius Heine
2017-11-17 16:53     ` [ext] Christian Storm
2017-11-17 18:14       ` Claudius Heine
2017-11-20  8:33         ` [ext] Christian Storm
2017-11-20  9:16           ` Claudius Heine
2017-11-29 18:53             ` Alexander Smirnov [this message]
2017-11-29 19:02               ` Jan Kiszka
2017-11-30  8:04                 ` Alexander Smirnov
2017-11-30 14:48                   ` Jan Kiszka
2017-11-30  9:31               ` Claudius Heine
2017-12-06 16:21                 ` Alexander Smirnov

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=c75334ef-75a7-1f34-df06-4dfe84112a64@ilbers.de \
    --to=asmirnov@ilbers.de \
    --cc=isar-users@googlegroups.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox