Anyone working on install-able packages (ipkg)

Hi,

Soon I should start work on install-able packages with ipkg. Actually I am thinking about opkg instead of ipkg, but that doesn't make any real difference.
A lot of work is waiting ahead, so maybe someone is already working on this?

Paulius

Hi Paulius,

I am not *yet* directly working on this, but in fact all the work I've been doing the last six months on the package infrastructure and the conversion of packages to these infrastructures is in preparation of the support of packages.

Some help going into this direction will be very appreciated. Let's discuss on the list the rough design ?

During the Buildroot meeting at Brussels in February, we discussed how we wanted to implement package removal, i.e be able to unselect a package from menuconfig and then remove it cleanly from $(STAGING_DIR) and $(TARGET_DIR). I think that some of the work required to do this might be common with package support. I'll clean up my notes and share them on the list.

Regards,

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Ok, here are my notes, they are the result of a discussion between Peter and I in Brussels in February. Of course, they are not necessarly final decisions and they can be discussed on the list.

Our discussion was not focused on install-able packages, but rather on being able to remove packages from the selection without having to rebuild everything from scratch. And we would like to do this
recursively: i.e, if you remove openssl for the selection, it should not only remove openssl's files in $(STAGING_DIR) and $(TARGET_DIR), but it should also rebuild the packages that have an optional dependency on openssl.

Therefore, we propose to (making the assumption that all packages use the generic or the autotools infrastructure or any later infrastructure that is based on the generic infrastructure) :

* Change the semantic of <pkg>-uninstall so that it removes the files installed by the package in the $(TARGET_DIR) and $(STAGING_DIR) directory, and remove stamp files so that next time 'make' is run, the package gets reinstalled. <pkg>-uninstall is *not* recursive, so that if other packages depend on <pkg>, they might be broken.

Of course, <pkg>-uninstall is implemented in a generic way in package/Makefile.package.in.

* Change the semantic of <pkg>-clean so that it does <pkg>-uninstall + removal of the source directory in build/. Like <pkg>-uninstall, <pkg>-clean is non-recursive.

* After the configure step, the name of the package being built should be added to the reverse dependencies files of the packages it depends on (listed in <pkg>_DEPENDENCIES). The reverse dependency file might be something like $(STAMP_DIR)/.<pkg>.rdeps.

* Before the installation (host, staging or target), save the result of a find in $(TARGET_DIR), $(HOST_DIR) and $(STAGING_DIR) in some temporary location.

* Then, do the installation steps as usual.

* After the installation, redo the finds in $(TARGET_DIR), $(HOST_DIR), $(STAGING_DIR) and diff it with their previous result. Store the difference (i.e list of files installed by package) in files named $(STAMP_DIR)/.<pkg>.{host,staging,target}.

* Implement <pkg>-remove, which:

1. Remove files listed in $(STAMP_DIR)/.<pkg>.{host,staging,target}

2. Call the <pkg>-remove target of all reverse dependencies (beware of possible duplicates)

3. Remove the reverse dependency file

4. Remove the install stamps of the current package

* Change how targets are added to $(TARGETS), and add the <pkgname>-remove target to $(TARGETS_TO_CLEAN) when the package is not selected. In the top Makefile, run the $(TARGETS_TO_CLEAN) targets before $(TARGETS) targets.

Of course, this is just a rough design, and many implementation details are left to be found/decided.

Paulius, do you have an idea on how you'd like to handle ipkg generation ? I have questions like :

* How do you handle dependencies ? As of today, the dependencies in Buildroot are expressed in terms of *source* dependencies, not *binary* dependencies.

* What do you put in the package ? The files usually installed in $(TARGET_DIR) ? How do we modify the package infrastructure so that the package installs its files to another location ?

Regards,

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Yes, that is problem... but source dependencies are quite close to binary ones. Bigger problem is host dependencies and here we may need to split dependencies.

Yes, files usually installed into TARGET_DIR would be installed into some temp dir and then packaged with ipkg. I have no idea how to modify infrastructure yet.