On Sat, Nov 9, 2019 at 3:12 PM Redacted sender c.a.venditti for DMARC <
dmarc-noreply@xxxxxxxxxxxxx> wrote:
On Friday, November 8, 2019 4:58 PM, Michael Stapelberg <
michael+distri@xxxxxxxxxxxxx> wrote:
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.
I know, my suggestions were meant to help using distri as a foundation for
more than what it was originally conceived to demonstrate.
Attracting more people can bring even more ideas. I really think this has
a lot of potential, in fact it will be the main part in the case study for
my undergraduate degree thesis.
I missed you had a roadmap for your posts in issue #4. Having read with
more attention all the open issues may have made a lot more clear before.
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.
I totally see your point. I'll look forward for your article :)
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?
I was complaining about having to run distri scaffold with the new url
instead of just changing the version in a single line (yeah, I'm
dramatically lazy) but it's for sure not a problem. Also, current approach
is not only good enough but possibly more elegant. The only complain is
that it overrides the previous build.textproto when it could just change
the relevant lines (or have an option to do so, as new version of packages
are probably going to have the same dependencies and require a mostly
identical build configuration)
Just send a pull request? :)
Of course :)
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? :)
Again, there's an open issue about having an installer. I didn't see it
and it's probably what I needed but I could easily manage to do what I
wanted anyway, it just took a little longer
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.
Understood. I suppose the right approach would be to defer the removal if
some file is still opened (maybe to the next boot?)
