Building a package without root, su, sudo, chroot or fakeroot
Not only can it be done, that is how it should be done.
Packaging is the activity of taking the output of "make install" and creating a package that can then be distributed and loaded on similar machines without development environments.
Packages have many other advantages over "make install" include opportunity for review, updates, removal, versioning, partial failure, distribution by repository and checking for conflicts.
So lets look at the mechanisms with real world examples
Solaris
Goal is to assemble a prototype file with pkginfo and depend along with source files.
The pkgmk will then assemble these into a package directory structure then pkgtrans can convert to a linear file,
The prototype file contains a list of files with their attributes and paths and the source to use which is used to generate the pkgmap.
The package is a tar file with special files at the root.
-rw-r--r-- 0 root wheel 1526 Jan 1 1970 +COMPACT_MANIFEST
-rw-r--r-- 0 root wheel 400756 Jan 1 1970 +MANIFEST
-r-xr-xr-x 0 root wheel 4022 Dec 20 21:30 /usr/dt/bin/dtsession_res
-r-xr-xr-x 0 root wheel 389944 Dec 20 21:30 /usr/dt/bin/dtmailpr
-r-sr-xr-x 0 root wheel 227560 Dec 20 21:30 /usr/dt/bin/dtsession
-r-sr-xr-x 0 root wheel 51488 Dec 20 21:30 /usr/dt/bin/dtappgather
-r-xr-xr-x 0 root wheel 61816 Dec 20 21:30 /usr/dt/bin/dtterm
-r-xr-sr-x 0 root mail 1277616 Dec 20 21:30 /usr/dt/bin/dtmail
OpenBSD
A CONTENTS file is written with a list of the files and their attributes. The pkg_create tool takes this along with other meta data and creates a tar archive.
A Debian package is an "ar" library archive containing at least three entries, debian-binary, control.tar. and data.tar.. The sequence in the archive is important.
The control.tar.* contains the meta data and install and removal scripts
The data.tar.* contains the file system contents itself the permissions come from the tar file itself, see section on tar permissions.
If you use tar in its simplest mode the attributes, group and user will belong to the file creators. For distribution you normally want these set to root:root or 0:0, this can be done
With GNU tar with --owner=0 and --group=0.
If you need to assemble a single tar file with files with various owner and group this can be done by creating individual tar files for each set of files with that owner:group combination and then concatenating onto the base tar file with the root:root files.
This should be done with "tar --catenate" to ensure the tar records are recorded correctly.
How Make Install can help
The best way for make install to help all these systems is to treat "make install" as sending a stream of files using the "install" program. The packaging system can then use its own version of the install program to collect files and data in order to assemble the package. For this system to work correctly, "make install" needs to call "install" once and only once per file and include all the permissions, user and group in that single call.
If that system was working correctly then there would be no need for the DESTDIR environment variable, the location of the temporary accumulation of the packing data is private to the install program and the packaging system. To "make install" it is effectively a write only stream of files, instead of "$(DESTDIR)" being the important piece of information, it is "$(INSTALL)".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, all of those good things I suggested have now been implemented at rhubarb pi. If you are using Gentoo or Arch then use the appropriate ebuild or PKGBUILD according to the OS. For the rest, use the packaging system to create an OS specific package without su, sudo, chroot or fakeroot.
A couple of additions are
Solaris builds CDE build twice, once in 64 bit mode the second in 32 bit mode. It uses the 64 bit compilation for /usr/dt/lib/amd64 and the 32 bit build for everything else.
The RPM and Debian builds extract the include, man3 and static libraries into a second development package.
There are places in the CDE build that assume fakeroot, but this is not available on all platforms ( eg slackware, OpenBSD ), so the use of fakeroot is faked. Instead of using fakeroot it adds custom versions of chmod, chgrp and chown onto the path to capture the intent.
So the end result is you can happily built CDE within a docker container or other virtual machine ( not as root, of course), and then install the resulting package on any other system.
Have fun.
Last edit: Roger Brown 2021-12-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying to set up CDE on a Librem13 laptop by Purism running PureOS
(Debian derivative).
Once in the wiki there was a startxsession.sh script but now it has been
removed(?)
I do not see how to set properly the locale if not en_US, without this
script.
It seems that LANG from /etc/locale.conf is ignored. But if from cde.desktop
instead of executing Xsession this is changed to startxsession.sh and
the latter
script exports LANG before executing Xsession everything works.
So if startxsession.sh has been removed how to setup properly the LANG
variable?
Moreover, some solution with HiDPI must be found. I have tried several
options with xrandr I found around the internet but none has worked.
Actually this issue is the only one that forces me not using CDE on my
laptop.
Most modern laptops have high resolution monitors and CDE can't be used
with them. Everything is too tiny.
Language should be a property associated with the logged in user. If you are already logged in, then scripts should not be changing your language, that is something you should be doing as part of your login.
I am using a debian based system with no /etc/locale.conf but have the required locales for CDE in /etc/locale.gen, for example
So if already logged in, then ( in my opinion ) it is correct for CDE to use the already logged in users language settings.
If I login with "dtlogin" and then in terminal
$echo$LANG
C
Dtlogin presents an option for the user to select their language, the screen will then rebuild in the new language. When you login then dtlogin will set up LANG to respect the users choice, and can then be one of
C
de_DE.UTF-8
en_US.UTF-8
es_ES.UTF-8
fr_FR.UTF-8
it_IT.UTF-8
as per the options on the dtlogin. If you login using dtlogin then do echo $LANG in a terminal it will show selected language.
Regarding screen size, the size of the frame and text used by the CDE window manager can be changed in the "Font" section in the "Style Manager". If you select a larger font, then the CDE window elements should use that setting. You will need to log out and log in again for the window manager to use the new setting. The maximum I could set mine to based on the dialog was 7 but that gave a font double the default size.
Last edit: Roger Brown 2021-12-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the answer. I will check what you wrote about locales.
About font sizes it is not easy to fix it for non originally supported
locales.
I am in el_GR.UTF-8 and currently I can not find good Greek fonts for sizes
above 4. If at some point CDE manages to see and use scalable fonts
(does it?)
what you suggest may work for non Latin languages such as Greek.
Antonis.
On 12/31/21 3:13 PM, Roger Brown wrote:
Language should be a property associated with the logged in user. If
you are already logged in, then scripts should not be changing your
language, that is something you should be doing as part of your login.
I am using a debian based system with no /etc/locale.conf but have the
required locales for CDE in /etc/locale.gen, for example
So if already logged in, then ( in my opinion ) it is correct for CDE
to use the already logged in users language settings.
If I login with "dtlogin" and then in terminal
$ echo $LANG
C
Dtlogin presents an option for the user to select their language, the
screen will then rebuild in the new language. When you login then
dtlogin will set up LANG to respect the users choice, and can then be
one of
C
de_DE.UTF-8
en_US.UTF-8
es_ES.UTF-8
fr_FR.UTF-8
it_IT.UTF-8
as per the options on the dtlogin.
Regarding screen size, the size of the frame and text used by the CDE
window manager can be changed in the "Font" section in the "Style
Manager". If you select a larger font, then the CDE window elements
should use that setting. You will need to log out and log in again for
the window manager to use the new setting. The maximum I could set
mine to based on the dialog was 7 but that gave a font double the
default size.
I change the subject (to locale settings+HiDPI) but the subject does not
change
and again it is Building etc... sorry for this but I do not understand
what is going on with the subjects
of the emails.
A.
On 12/31/21 3:26 PM, Antonis Tsolomitis wrote:
Thanks for the answer. I will check what you wrote about locales.
About font sizes it is not easy to fix it for non originally supported
locales.
I am in el_GR.UTF-8 and currently I can not find good Greek fonts for
sizes
above 4. If at some point CDE manages to see and use scalable fonts
(does it?)
what you suggest may work for non Latin languages such as Greek.
Supporting scalable fonts certainly looks like a good suggestion if it is not already implemented. Likewise, the current supported set is DE/EN/ES/FR/IT. Work would be required to extend that list.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Building a package without root, su, sudo, chroot or fakeroot
Not only can it be done, that is how it should be done.
Packaging is the activity of taking the output of "make install" and creating a package that can then be distributed and loaded on similar machines without development environments.
Packages have many other advantages over "make install" include opportunity for review, updates, removal, versioning, partial failure, distribution by repository and checking for conflicts.
So lets look at the mechanisms with real world examples
Solaris
Goal is to assemble a prototype file with pkginfo and depend along with source files.
The pkgmk will then assemble these into a package directory structure then pkgtrans can convert to a linear file,
The prototype file contains a list of files with their attributes and paths and the source to use which is used to generate the pkgmap.
When the package is installed the pkgmap will be used to determine the file attributes.
The packaging format is a standard, the stream form uses cpio: http://www.sco.com/developers/devspecs/gabi41.pdf
Redhat/RPM
Creating an RPM is very similar in principle to Solaris, an rpm.spec is written which lists all the files and their attributes.
The tool rpmbuild will take the rpm.spec and generate the rpm file itself. The RPM file itself is based on cpio.
FreeBSD
The tool pkg is used to create a package from PLIST and MANIFEST files. The PLIST lists the directories and files with their attributes.
The package is a tar file with special files at the root.
OpenBSD
A CONTENTS file is written with a list of the files and their attributes. The pkg_create tool takes this along with other meta data and creates a tar archive.
Content file override permissions in archive
On installation the CONTENTS file is used to determine permission.
NetBSD
The CONTENTS file is written listing all the files are their permissions.
The pkg_create takes this file and BUILD_INFO and creates the tar archive with the additional meta data files.
l
ArchLinux
Now here ArchLinux actually does use fakeroot to create the package from PKGBUILD. That is their choice.
Slackware
Slackware has a packaging tool that needs to run as root but is not required to create a conforming package.
The package is a tar archive with a special root record, an install directory with slack-desc and doinst.sh for handling symbolic links.
File attributes come from the tar file itself, see section on tar permissions.
Debian
A Debian package is an "ar" library archive containing at least three entries, debian-binary, control.tar. and data.tar.. The sequence in the archive is important.
The control.tar.* contains the meta data and install and removal scripts
The data.tar.* contains the file system contents itself the permissions come from the tar file itself, see section on tar permissions.
-r--r--r-- root/root 114 2021-12-20 19:18 etc/pam.d/dtsession
-r--r--r-- root/root 149 2021-12-20 19:18 etc/pam.d/dtlogin
-r-sr-xr-x root/root 38584 2021-12-20 19:20 usr/dt/bin/dtappgather
-r-xr-xr-x root/root 73368 2021-12-20 19:20 usr/dt/bin/dtterm
-r-xr-xr-x root/root 219968 2021-12-20 19:21 usr/dt/bin/dtsession
-r-xr-xr-x root/root 4008 2021-12-20 19:18 usr/dt/bin/dtsession_res
-r-xr-xr-x root/root 331292 2021-12-20 19:21 usr/dt/bin/dtmailpr
-r-xr-sr-x root/mail 1072592 2021-12-20 19:21 usr/dt/bin/dtmail
Tar permissions
If you use tar in its simplest mode the attributes, group and user will belong to the file creators. For distribution you normally want these set to root:root or 0:0, this can be done
With GNU tar with --owner=0 and --group=0.
If you need to assemble a single tar file with files with various owner and group this can be done by creating individual tar files for each set of files with that owner:group combination and then concatenating onto the base tar file with the root:root files.
This should be done with "tar --catenate" to ensure the tar records are recorded correctly.
How Make Install can help
The best way for make install to help all these systems is to treat "make install" as sending a stream of files using the "install" program. The packaging system can then use its own version of the install program to collect files and data in order to assemble the package. For this system to work correctly, "make install" needs to call "install" once and only once per file and include all the permissions, user and group in that single call.
If that system was working correctly then there would be no need for the DESTDIR environment variable, the location of the temporary accumulation of the packing data is private to the install program and the packaging system. To "make install" it is effectively a write only stream of files, instead of "$(DESTDIR)" being the important piece of information, it is "$(INSTALL)".
Hi, all of those good things I suggested have now been implemented at rhubarb pi. If you are using Gentoo or Arch then use the appropriate ebuild or PKGBUILD according to the OS. For the rest, use the packaging system to create an OS specific package without su, sudo, chroot or fakeroot.
A couple of additions are
Solaris builds CDE build twice, once in 64 bit mode the second in 32 bit mode. It uses the 64 bit compilation for /usr/dt/lib/amd64 and the 32 bit build for everything else.
The RPM and Debian builds extract the include, man3 and static libraries into a second development package.
There are places in the CDE build that assume fakeroot, but this is not available on all platforms ( eg slackware, OpenBSD ), so the use of fakeroot is faked. Instead of using fakeroot it adds custom versions of chmod, chgrp and chown onto the path to capture the intent.
So the end result is you can happily built CDE within a docker container or other virtual machine ( not as root, of course), and then install the resulting package on any other system.
Have fun.
Last edit: Roger Brown 2021-12-31
I am trying to set up CDE on a Librem13 laptop by Purism running PureOS
(Debian derivative).
Once in the wiki there was a startxsession.sh script but now it has been
removed(?)
I do not see how to set properly the locale if not en_US, without this
script.
It seems that LANG from /etc/locale.conf is ignored. But if from cde.desktop
instead of executing Xsession this is changed to startxsession.sh and
the latter
script exports LANG before executing Xsession everything works.
So if startxsession.sh has been removed how to setup properly the LANG
variable?
Moreover, some solution with HiDPI must be found. I have tried several
options with xrandr I found around the internet but none has worked.
Actually this issue is the only one that forces me not using CDE on my
laptop.
Most modern laptops have high resolution monitors and CDE can't be used
with them. Everything is too tiny.
A.
Language should be a property associated with the logged in user. If you are already logged in, then scripts should not be changing your language, that is something you should be doing as part of your login.
I am using a debian based system with no /etc/locale.conf but have the required locales for CDE in /etc/locale.gen, for example
So if already logged in, then ( in my opinion ) it is correct for CDE to use the already logged in users language settings.
If I login with "dtlogin" and then in terminal
Dtlogin presents an option for the user to select their language, the screen will then rebuild in the new language. When you login then dtlogin will set up LANG to respect the users choice, and can then be one of
as per the options on the dtlogin. If you login using dtlogin then do echo $LANG in a terminal it will show selected language.
Regarding screen size, the size of the frame and text used by the CDE window manager can be changed in the "Font" section in the "Style Manager". If you select a larger font, then the CDE window elements should use that setting. You will need to log out and log in again for the window manager to use the new setting. The maximum I could set mine to based on the dialog was 7 but that gave a font double the default size.
Last edit: Roger Brown 2021-12-31
Thanks for the answer. I will check what you wrote about locales.
About font sizes it is not easy to fix it for non originally supported
locales.
I am in el_GR.UTF-8 and currently I can not find good Greek fonts for sizes
above 4. If at some point CDE manages to see and use scalable fonts
(does it?)
what you suggest may work for non Latin languages such as Greek.
Antonis.
On 12/31/21 3:13 PM, Roger Brown wrote:
I change the subject (to locale settings+HiDPI) but the subject does not
change
and again it is Building etc... sorry for this but I do not understand
what is going on with the subjects
of the emails.
A.
On 12/31/21 3:26 PM, Antonis Tsolomitis wrote:
This is not an email list server. If you want to create a new topic then create one in
https://sourceforge.net/p/cdesktopenv/discussion/general/
Further investigation shows this changes the Font elements in
$HOME/.dt/sessions/current/dt.resourcesFor example, when set at 4, it has
Font: -dt-interface user-medium-r-normal-m*-*-*-*-*-*-*-*-*When set at 7 it has
Font: -dt-interface user-medium-r-normal-xxl*-*-*-*-*-*-*-*-*But these are to be managed by CDE Style Manager, do not change them manually.
Supporting scalable fonts certainly looks like a good suggestion if it is not already implemented. Likewise, the current supported set is DE/EN/ES/FR/IT. Work would be required to extend that list.