Build dependencies on system should be installed via a meta-package

[Marco Trevisan (Treviño)]

Snapcraft should generate build dependencies by creating a meta package (as mk-build-deps does for debian files), such as $SNAPCRAFT_PROJECT_NAME-version-buidld-deps.deb that depends on the required build-packages.

In this way by removing this meta-package, the system goes back to its clean state.

Optionally, as a first step, you could apt-mark auto all the packages that have been installed as "auto", so that they can be easily removed later on with "apt-get autoremove", keeping the system clean.

[Marco Trevisan (Treviño) (3v1n0)]

In general I'd just prefer the packages to be only downloaded locally though, extracted in parts/build-deps and then updating all the environment variables to build using that path.

Redefining PATH, CPATH, LIBRARY_PATH, LD_LIBRARY_PATH, LD_RUN_PATH, XDG_DATA_DIRS, XDG_CONFIG_DIRS, QML2_IMPORT_PATH, PKG_CONFIG_PATH, PYTHONPATH, GI_TYPELIB_PATH with that prefix for compiling should be in general enough (probably there would be some failing cases with packages using tools such as sdl-config).

[Sergio Schvezov (sergiusens)]

El 08/11/16 a las 09:02, Marco Trevisan (Treviño) escribió:
> In general I'd just prefer the packages to be only downloaded locally
> though, extracted in parts/build-deps and then updating all the
> environment variables to build using that path.
>
> Redefining PATH, CPATH, LIBRARY_PATH, LD_LIBRARY_PATH, LD_RUN_PATH,
> XDG_DATA_DIRS, XDG_CONFIG_DIRS, QML2_IMPORT_PATH, PKG_CONFIG_PATH,
> PYTHONPATH, GI_TYPELIB_PATH with that prefix for compiling should be in
> general enough (probably there would be some failing cases with packages
> using tools such as sdl-config).

Download and unpacking is a feature of stage-packages, but it will be
more problems with build-packages as this process won't trigger postinst
scripts.

What you really probably want to look into is working inside a container.

[Marco Trevisan (Treviño) (3v1n0)]

> What you really probably want to look into is working inside a
> container.

Which I do... But that's not a good reason for loosing track of what
I've installed there. So, well, first suggestion is still the one
should be applied IMHO.

[Sergio Schvezov (sergiusens)]

https://github.com/snapcore/snapcraft/pull/891