I have started working on adding deb support to RTEMS Deployment.
From what I have understood till now. waf builds a tar first and then we build a rpmspec file and then user manually invokes rpmbuild to build a .rpm package. Is this the correct flow? Or am I missing something. I plan on mimicking the same behaviour for .deb with deb specifics.
Have you read through the topics in Deployment ?
Yes I have gone through them and understood what I stated earlier.
I have some initial success in generating debian control file and subsequently a .deb package.
I have a few questions though.
rpmspec file can contain commands which can be run at package build time. One being tar jxf %{rsb_tarfile} -C %{buildroot}. As far as I know control files cannot do that and would require the user to manually unpack the tar somewhere.
Is it acceptable behaviour?
I could use debain/rules and dpkg-buildpackage that would automatically extract the TAR specified in debian/control file in @TARFILE@ variable, but it would still be required to prepare deb_buildroot/ tree (ie. adding debian/rules, debian/control, debian/changelog, etc) manually via user. Should I make a helper python script that does all of it?
How should I proceed?
@kiwichris any insights you may have for the possible direction of this project?
Thanks for looking at this project.
I am fine with the addition of a command to deployment, for example rtems-pkg that invokes the Debian packager performing any prep work such as untaring the tar file. It may be nice to add rpmbuild to that command so it can be a simplified way to handle this for Debian and other packing commands. This command can be Python giving you access to the internal tar support.
Debian and Ubuntu are hard because the packaging rules try and force you to install under /usr. I consider the forcing here as overreach by Debian. There are valid use cases for users building packages that reside outside the Debian ecosystem.
The issue with using /usr is the complexity you get with any shared parts of GCC, Binutils and other pieces being installed. For example you have two projects one on ARM and the other on AARCH64. The GCC commands would be aarch64-rtems7-gcc and arm-rtems7-gcc. These commands are fine in /usr/bin because the names are different. The issue is with the /usr/shared parts as the files installed under there are the same and the second installed package would overwrite the first if forced to install and removing either package erases the shared parts breaking the remained package.
A correctly packaged system would isolate the common pieces into a shared package and the architecture specific parts would add dependencies to the shared package. I see this level of packaging as out of scope for us (at this point in time) and unnecessarily complicated. We work around this problem manually by using different build install paths. The shared package gets harder when you then want to move to RTEMS 8 and the same files are under /usr/shared but the version of the files may have changed if RTEMS 8 has a newer version of GCC.
Can you package a build with a prefix of /opt/rtems/7?
Thanks for replying! @kiwichris
An additional command makes it a lot easier. I will make sure I am able to integrate all packaging formats to this command.
I understand the Debian standard as you have stated here. I can surely package a build with a prefix of /opt/rtems/7.
Also on a side note, are you the same chris mentioned on the issue as possible mentor?
If so I have a few questions related to GSoC that I would like to discuss on DM if you permit.
I have built the skeleton for the commandline utility rtems-pkg.
I plan on making it modular so that adding more packaging support is simpler. In the above image deb is one of the modules I made for it.
I will be adding it to my GSoC proposal as well.
Other than that I have also packaged a build with /opt/rtems/7 as the prefix.
We don’t generally take DMs during the proposal period. There are too many applicants and not enough mentors to handle that kind of load.
Oh I totally understand that. Thanks for clarifying.
GSoC guidelines mention getting your proposal reviewed by the mentor as soon as possible. I don’t totally understand how should I do that. Can you guide me a bit on that matter?
Once you have added it to your tracking page, you can ping potential mentors here or on discord to ask if they can take a look.
@kiwichris In case you missed it over Discord; Can you have a look over my proposal? Here is the link to it.
Thanks!
