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!
# Package
%define arch noarch
I have been looking into the existing packaging system and found this a bit odd. Why are we setting the package architecture to all in rpm.spec.in?
Shouldn’t it be amd64 or arm depending on for what architecture the toolchain was compiled for? Why are we doing this? Or did I miss something?
Good question. I do not remember why?
Is the setting the architecture of the host the tools run on or the architecture of the code the cross-compilers generate code for?
i Just checked it is actually doing nothing…
BuildArch variable is never set in the rpmspec file. arch var is unused. Not sure what purpose it serves.
rpmbuild defaults to host machine architecture if BuildArch isnt set. But debian control file and freebsd manifest doesn’t do this. They explicitly requires arch variable to be set. Should I set it to the machine arch on which packaged binary is going to run?
i feel we should set it to arch of the machine going to run those binaries.
Setting to all would allow for example an arm user to install amd64 binaries which wouldn’t work and would be inconsistent.
This makes sense. Please create an MR for the change?
Thanks
I have created a MR fixing the issue keeping future developments in mind.
As different packaging systems expect different names for same arch type, I have created a map to keep track of naming conventions used by different packagers. Eg. deb uses amd64 while rpm uses x86_64.
Please have a look at it and suggest any changes if required.
@kiwichris Just a quick reminder.
I have created a MR on RTEMS Deployment repo. Waiting for your feedback!
Also can you have a look over my GSoC Proposal?
As the application deadline is nearing its end, it would be very helpful to get your feedback on what can I improve upon.
Thanks!
Apologies for inactivity for past few days. I have been caught up with lab exams and poor health conditions.
I am now well and back to researching.
I have been reading about freeBSD packaging system and found out specific arch flag that they require.
Should we follow the “proper” way using strict ABI triplets (e.g., FreeBSD:15:amd64) or a “forcing” way with more generic strings?
The proper way ensures a seamless pkg install but requires building for every OS version, while the forcing way allows a universal package that may require a -f flag.