[distri] Re: Building packages and packing images
- From: Michael Stapelberg <michael+distri@xxxxxxxxxxxxx>
- To: distri@xxxxxxxxxxxxx
- Date: Fri, 8 Nov 2019 16:58:35 +0100
Hey,
On Fri, Nov 8, 2019 at 2:21 PM Redacted sender c.a.venditti for DMARC <
dmarc-noreply@xxxxxxxxxxxxx> wrote:
Hello,
I've discovered distri a few months ago and I recently began my dive into
it. I really want to thank Michael for all this great work. This is amazing.
Thanks, I’m glad you find it useful!
There are a few things I think could make contributing to the project
easier:
Before I talk about the specifics, note that distri is not looking for
contributions. Its primary objective is to be a research vehicle, and to
explore/demonstrate the feasibility of a number of ideas.
As some have already pointed out, at first building packages is not
intuitive and even if the documentation is good it's not straightforward.
I'm accustomed to Arch Linux PKGBUILDs (so just shell scripts) and they are
(and feel) way more powerful and intuitive than writing every command you
need one argv at a time.
I haven’t gotten around to publishing my article about declarative
packaging yet, so let me just give you a few short notes here :).
The flexibility of most existing package management systems (e.g. Debian’s
debian/rules Makefile, Arch’s PKGBUILD shell scripts, …) comes with the
huge downside of precluding almost all programmatic insight. While it might
be easy for humans to write a shell script, parsing and understanding the
intent behind a shell script is essentially impossible for a computer
program.
By allowing _only_ declarative packaging, distribution-wide changes can be
done much more easily in distri, and supporting infrastructure is easier to
build.
Note that specifying build_steps at all is an escape hatch from declarative
packaging and should only be used in a few rare cases. Currently, 88 of 440
packages need build_steps, but the long-term goal is to drive that number
down significantly. What I’m trying to get at is: the current way of
specifying build_steps is intentionally cumbersome and annoying to nudge
people towards doing things declaratively.
It's also easier to update to a new version because if there are no big
changes upstream, one has only to increase the version number that is
referenced wherever needed (including source tarballs' url).
The same is true for distri packages right now, see e.g.
https://github.com/distr1/distri/commit/b7fffc9d7d2f5a2152caf669a935476ced12dad2.
Why did you come to the conclusion that more work would be needed?
Would something alike be a better approach? I'm unsure how this could be
done with Protocol Buffers and how time consuming can be but I'm definitely
willing to help for this.
On a side note: how should I contribute packages? (someone may find at
least tmux useful, even if it's quick to write your build.textproto for
it)
Just send a pull request? :)
I'm messing with the initramfs right now and I found difficult to work on
this. I understand the goal of the project being to demonstrate a different
approach to package management and this may be out of scope but making the
pack command more flexible
What sort of flexibility are you looking for? Given that we have
instructions for running distri in qemu, docker, virtualbox, lxd, google
cloud and on real hardware from a USB memory stick, I think we are quite
well positioned already? :)
Personally, I use qemu, which has an iteration time measured in seconds
(including the distri pack command).
may help really a lot if one wants to mess around with the system. Maybe
even give a (kind of) straightforward way to install distri from a running
system (I wanted to try a few ideas and I needed a btrfs root. It's time
consuming to set up everything).
One last thing: Am I missing something very obvious or there's not a way
to remove a single package once installed?
You’re not missing anything: removing packages is not implemented right now.
One reason why that isn’t as trivial as removing the backing image files
from /roimg is that I haven’t extensively thought about (or experimented)
how running applications behave when you remove the file system they’re
being run from—think deleting zsh-4.6.2 after upgrading to zsh-4.6.3, but
you still have a shell running zsh-4.6.2 in a screen session.
Thank you again Michael for this great project.
Kind regards,
Carlo Antonio
Other related posts:
