On Thu, 17 Oct 2019 at 14:15, Randy Barlow <bowlofeggs@xxxxxxxxxxxxxxxxx> wrote:
>
> Could we think of a solution that is simple so that packagers can more
> easily understand how it works?
The issue is how many different choices are you allowing and where you
are allowing them to be made. A lot of the gentoo and nixos seem to be
made on the personal system. I choose how I want to build out my box
and it builds itself to do that. If you push the decisions up into the
central build system, then you need to start working with other people
and letting them mess with your decisions. That means various design
choices no longer are simple.. and are less technical. They are
instead policy and bureaucracy in order to grease the interactions and
different opinions to get a compromise or in the end a hard decision
even when no one wants it.
The problem I found with both the documentation and most of our
conversations is that we have been trying to treat this as a
technology problem when it is a social one. A distribution is a social
contract between different packagers to make a 'product' (I am trying
for a word which is less commercial so if you know one.. use it
instead). A module is just a smaller social contract where we need to
make a set of things work together in a way that works both with the
larger product and its own self. Most of the rules in writing a good
spec file are meant to make it easier that someone else can maintain
it later.. that is a social requirement. We might dress it up with
'MUST have %{0fedora}' but it is a social contract. The rpm doesn't
care if I use %0fedora or 1. [Man I have digressed into finding the
source of the Nile somewhere.. ok pull it together smooge]
In the end, we need to work out what the social wants/needs for the
technological marvel we create are before we build it. The larger the
number of people you are working with said marvel, the more important
that social rules/upkeep is. Putting the brakes on the car after it is
going 100mph is a little late.
> Or better, can we employ a solution
> that another distribution has developed?
Not without using their packaging system, their build system and their
other design choices. Working out slots would mean needing to make
changes into how RPM works and how yum/dnf work. It might also not be
possible because a bit of Gentoo's magic is letting the local system
build all the different slot choices instead of having to build all
the combinatorics that having 3 different glibc and N gcc compilers
would need. To do the magic NixOS does.. we need to eject the FHS and
use a similar system. At that point, we aren't developing Fedora
anymore.. we are developing a clone of NixOS or Gentoo. [And there
would be no magic way to move from a Fedora 33 system to Fedora-Nix-34
or Fedora-Gen-34.. at which point we might as well just call the whole
thing from scratch.] If we are going that far we might as well rewrite
conary in python3 or rust and start from there...
So any solution will have to 'learn' the lessons of these groups but
design and write a solution from scratch to meet them.
--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
