[Dev] your-system-sanity

grizzlyuser grizzlyuser at protonmail.com
Wed Jul 31 13:55:56 GMT 2019

In my understanding, downstream distributions should always work with upstream
first. If issues cannot be resolved upstream - make one step down the stream and
work on that layer. Then the process repeats if there are multiple intermediate
downstream layers and if necessary. If there's something critical though,
downstream can decide to deploy a temporary solution themselves until the issue
is resolved upstream. This can be anything from documentation of the workaround
to actual patches or customizations.

On Wednesday, July 31, 2019 4:28 AM, Freemor <freemor at freemor.ca> wrote:
> Though it did seem that they added some ./configure options or the like to
> change how it behaves (I'll have to find it again. Will post it here when I
> do).

Following the above principle, if the issue has already been reported upstream,
then has it already been reported to Arch Linux bug tracker? If there are
configuration options available, then what about shipping the package with the
configuration or patch that allows it to work well with the rest of the system?
Parabola / Arch is a distro, and of course they can do that stuff to
maintain system stability.

AFAIK, downloading of non-free assets has been already discussed, and one of the
ideas was that allowing to download non-free is not equal to recommending
non-free. What I understood was, for example, if some package has hard-coded
download links to non-free things, then it's an issue. And it's not, if it has a
link to a repository where both free and non-free things are distributed and
it's up to the user to decide what to download.

The issue of package managers being able to install non-free, looks complex.
Ideally it'd be solved if each of them (including pacman) fully supports all of
the following:

1. license filtering, so users can configure the PM to filter packages and all
of their dependencies based on their licenses or license groups;

2. reproducible builds.

In this case it looks like it wouldn't matter from which repository the package
is downloaded, being it 1st- or 3rd-party. But that's in ideal world, of

About the name of the package: there are lots of insane stuff in the software
world... What about changing the name to something more specific?

More information about the Dev mailing list