[RFC] Technical proposal for fakeroot removal
by Max Rees
Hello,
As work towards the minimal viable product of APK Foundry nears
completion, I have been thinking of large scale trybuilds that can be
done in order to fully test its functionality. I think one such trybuild
that would also serve a functional purpose would be to begin work on
removing fakeroot(1) from the packaging process.
Most of the utility of using fakeroot in abuild currently is in order to
assign arbitrary user or group ownership to files before they are added
to the final .apk file. It does so by using an LD_PRELOAD hack to shadow
the libc's relevant functions, and uses a daemon to keep track of the
fake ownership of files.
As of this writing, there appears to be:
* 24 packages that use the $pkgusers and $pkggroups directives.
* 3 packages that only use the $pkggroups directive.
* 0 packages that only use the $pkgusers directive.
* 12 packages that use chown(1) or chgrp(1) in the APKBUILD, 8 of which
are not included in any of the above.
And an unknown amount of packages that perform their own chown or chgrp
during the vendor's installation process (this may later be estimated by
examining all available apks and checking for user, group != root).
In regards to a replacement, I think in absence of fakeroot we can
instead declaratively specify which files need special ownership
requirements through the use of libarchive's mtree(5) functionality. The
mtree file format is a BSD invention that describes the contents of a
tar file and allows for arbitrary specification of user and group
ownership as well as permissions, file type, etc.
By generating a de facto mtree for the package contents with
--uname root --gname root and allowing the packager to override this
mtree where necessary, I think the need for fakeroot can be mostly
eliminated.
This of course would have the side effect of tying abuild to the
libarchive implementation of bsdtar at runtime, unless we were to ship
our own utilities (built from libarchive I presume) to handle the
mtrees.
abuild would have an opaque shell function or similar that allows
specifying the file type, user ownership, group ownership, and
permissions for a file in the package. This function would then write to
a file in the control directory that contains the generated mtree
override(s), and merges that with the default root:root mtree before
using the merged mtree to build the data.tar.gz file.
For example, system/abuild itself needs to install /var/cache/distfiles
with abuild group ownership. The APKBUILD would have something like the
following instead of a chgrp:
> amtree -g abuild "$pkgdir"/var/cache/distfiles
The amtree function would translate this into an mtree entry and add it
to the $controldir/.mtree override file:
> var/cache/distfiles gname=abuild uname=root mode=775 type=dir
After merging the overrides with the default root:root mtree, libarchive
then supports reading an mtree file as a description from which to build
a tar file, like so:
> tar -cf data.tar.gz --uname=root --gname=root @$controldir/.mtree
I specifically think that the mtrees would have to be built on the fly
(not statically / version controlled) because some packages will of
course have filenames that differ between architectures. Thus if you
need an mtree for each (architecture + subpackage) combination, things
can quickly balloon.
To make this a gradual process we can also add some option to $options
if necessary.
Thoughts?
Max
10 months, 3 weeks
Weekly Status Report: 2019-09-22
by A. Wilcox
Hello all!
This week has once again seen a primary focus on the specifications for
Horizon, and work on APK Foundry. There have been some other
interesting developments as well.
Web site
========
Top 5 referring sites to the Web site:
* 78: Google searches
* 75: DistroWatch
* 31: DuckDuckGo searches
* 27: Repology
* 23: Adélie.blog
Top 5 pages accessed (and homepage):
* 1175: /
* 251: /about.html
* 137: Horizon Specifications
* 57: /about-qa.html
* 36: /contribute.html
* 35: /team.html
Horizon
=======
Specification work on Horizon continues to be done, with an emphasis on
the disk partitioning portion of the system. Discussions about a syntax
for having comments in a HorizonScript were also had.
APK Foundry
===========
Max Rees (sroracle@) continues to work hard on the finishing touches of
APK Foundry. They have now successfully run AF jobs on four Tier 1
architectures.
musl
====
Dan Theisen (djt@) has been working on implementing the <fstab.h> APIs
in musl. This will allow us to package software like K3b and filelight.
General discussion
==================
Our community has graciously sent in some hardware donations this week.
An Apple Radeon 9200 was sent in to investigate some issues with
display on some models of eMac G4 and Mac mini. A new NVMe device for
the PPC64 builder was donated after the existing NVMe device was
destroyed by a freak accident[1]. More memory for the PPC64 builder has
also been donated. We thank our community very much for these generous
donations!
We are still in need of some monetary donations to make it through
October. If you have a bit to spare and want to show your support for
the work we're doing to provide high-quality libre software to everyone,
please consider contributing. You can find out how on our Contribution
page at < https://www.adelielinux.org/contribute.html >.
All of my best to you and yours,
--arw
[1]:
https://catfox.life/2019/09/22/cascading-failures-or-why-i-did-nothing-th...
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
1 year, 7 months
Serial Console on Live Media
by Dan Theisen
Hello all,
Yesterday I was attempting to install Adelie on a PCEngines APU3. This
board has no video output, but it does have a serial console, which is
the method that the manufacturer expects users to use to install and
manage their devices with.
I wrote an Adelie Live Beta4 ISO to a USB stick, booted up, and edited
the kernel command line to include "console=ttyS0,115200". The kernel
began booting as expected and spitting out kernel logs to the serial
console; it started services, and then failed to spawn a getty on the
serial console.
Looking into this issue on IRC, some contributors and I noticed that
while there are some config options specified for ttyS0 and ttyS1
devices in /etc/conf.d/gettys, neither will spawn a getty by default.
The live media should absolutely support installation via a serial
console. This is a use case that we should expect our users and
customers to need at some point, especially considering that devices
like I described in the first paragraph of this email actually exist.
After some further discussion in IRC, the community has come up with 3
possibilities for handling this situation:
1. Configure /dev/ttyS0 to be a serial console by default with no
further checks.
My thoughts: I am personally opposed to this solution. It was
mentioned in IRC that VirtualBox (and some other systems) might take
issue with the OS assuming that ttyS0 should be a system console. I also
think that it is bad for user choice.
2. Parse the Linux kernel CLI parameters for "console=" being specified,
and use the device listed.
My thoughts: This solution seems fairly reasonable to me. Some users
brought up potential issues with this solution, and I welcome them to
elaborate further on these issues in the discussion to follow this email.
3. Parse the Linux kernel CLI parameters for a custom key, such as
"getty=", and spawn a console on the specified device.
My thoughts: This solution also seems fairly reasonable to me. It
seems like the best option for user choice, but it has the downside of
being "non-standard" in terms of what a Linux user might expect. Users
would have to be aware of this functionality by reading the system
documentation or otherwise.
I'm bringing this to the mailing list in the hopes of fostering
discussion on this issue within the community, and coming up with the
best solution that we can come up with. Feel free to comment on the
options that we've come up with, or propose your own if you can think of
something that outweighs the benefits and pitfalls of the already
proposed solutions.
Thanks!
1 year, 8 months