Hi Vijai,

On 25/09/2019 09.41, Vijai Kumar K wrote:
> Hi All,
> 
> Starting this thread to discuss the base-apt features and limitations.
> 
> Here I am listing down some of the issues/features and possibly the
> need for them.
> 
> 
> 1. Support for adding source packages.
> 
> Currently we have support only for binaries. The corresponding source
> files could also be added. 

Yes. That would be required (AFAIK, but INAL) if the base-apt should be
used to distribute packages to the end-user as per GPL.

> 
> 
> 2. Support for using password protected keys.
> 
> It is a good practice to have the gpg key protected to have an additional
> level of security. Right now ISAR does not have provisions to use password
> protected keys.

There are two use-cases for base-apt AFAIK: Use it to distribute a
repository to the end user and for reproducible/offline build.

I agree that for the former having a password protected key for signing
the repo would be good. For the latter use-case though that might get
cumbersome.

Maybe we should split this use-case and have something different for
reproducible/offline build?

Also 'base-apt' is a bad name...

> 
> 
> 3. Support for specifying the signing key.
> 
> Right now, the signing mechanism uses the default gpg key of the system.
> This is problematic in many ways. Especially for CI. In the current
> implementation, eventhough we specify the key, we are not really using it.

Right, that needs to be fixed.

> 
> 
> 4. Support for adding packages only to base-apt.
> 
> Sometimes, we might need a package to be present in base-apt but not in
> the target yet. Things like dev & dbg packages. It would be good if we
> have something like BASE_APT_INSTALL which contains the list which would
> be populated only in base-apt.

If the base-apt should be used for distributing packages to the
end-user, it might also be useful to exclude certain packages.

> 
> 
> 5. Refactoring code to consolidate reprepro calls.
> 
> Right now, reprepro calls are spread across the build system. Its dependencies
> are spread across too(Handling envs like GNUPGHOME, distributions file etc).
> My first thought is to have a seperate module implemented to handle these
> calls.

Yes, that would be a good refactoring idea.

regards,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

           PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                             Keyserver: hkp://pool.sks-keyservers.net