[Dev] your-system-sanity
bill-auger
bill-auger at peers.community
Thu Aug 1 04:09:40 GMT 2019
related tracker issues:
https://labs.parabola.nu/issues/1035
https://labs.parabola.nu/issues/1904
On Tue, 30 Jul 2019 22:28:16 -0300 Freemor wrote:
> Which TPPMs fall into this category is up for discussion
probably all of them - ive been trying to compile a complete
list in redmine #1035 - even the relatively safe ones like guix
that respect the system and install to /usr/local/ or elsewhere,
can still over-ride installed system files because that
_wherever_ necessarily has priority in the user's $PATH - e.g.
if pip installed pip-pacman to /usr/local/, when the users types
the `pacman` command they will still get a video game or an X
error, or some GUI helper may silently fail (the latter is how we
discovered this problem IIRC) - luckily, the real pacman would
still exist but the user would need to type /usr/bin/pacman to
use it - IMHO all TPPMs are naughty and they should never be run
as super-user, and we should still warn about running them
as super-user, even if they do install to /usr/local/
or /guix/store/
On Tue, 30 Jul 2019 22:28:16 -0300 Freemor wrote:
> Do we warn about
> all TPPMs or do we only concern ourselves with the ones that
> Bork the system by default.
i think probably the only explicit warning is about AUR - that
should be expanded to treat AUR helpers, which are all
blacklisted, equally to any the TPPMs that are in parabola repos
- one could easily argue that it make no sense to blacklist AUR
helpers but to keep pip, rubygems, and the others - with the
exception of haskell cabal and maybe PECL, these are notorious
for not requiring free license or even license notices of any
kind - the AUR PKGBUILDs at least do generally specify the
license, and they generally have the pacman package in the
conflicts() array; making the AUR more libre-friendly and sane to
use than most TPPMs - there is a real oversight and inversion of
risk-assessment here
On Tue, 30 Jul 2019 22:28:16 -0300 Freemor wrote:
> Do we worry about TPPMs that offer non-free or should those be
> handled by the regular blacklist.txt
TPPMs can not be handled by the current blacklist system - that
is pacman-specific - we currently do not do anything about that
other than blacklisting AUR helpers - that question is the topic
of redmine #1035
On Tue, 30 Jul 2019 22:28:16 -0300 Freemor wrote:
> Several users were wanting games with the built in ability to
> download non-free culture assets. I feel this is beyond that
> scope of your-system-sanity as it's purpose is system
> stability.
if the only problem to solve is system stability, the proper
solution is to patch these "elephants in the china shop" so that
they install to /usr/local/ as per the FHS - the best solution
is, of course, to convince arch that they should do it, as arch
does claim to follow the FHS
generally, eliminating the problem at the root is better than
compensating for it or resorting to warnings - in this case,
there is no valid use case for wanting pip to clobber files that
pacman installed - arch should have never allowed this to happen
i say there is no valid use-case for running any TPPM as
super-user; and i would not want to spend much time accommodating
that use-case - if someone deems any software to be such an
essential part of their system, it would be wiser to create a
PKGBUILD for it that will play nicely with the system dependency
chain - if the program can not run against the current arch
libs, it probably is in desperate need of maintenance; or it
should be installed in a chroot, VM, or $HOME - i.e. it would
not bother me to remove the --global switch from pip so that it
will always install to the PWD, and only _if_ it already has
permission
On Tue, 30 Jul 2019 22:28:16 -0300 Freemor wrote:
> it could break builds in abslibre
> if they
> require things like cargo,gems,maven,etc
would it though? - doesnt libremakepkg already disable the
network during build? - i would say that any build that requires
the network is FTBS by design; and we should not want any such
program in the system - remember now, that you just verified
that the source-balls are currently imploded before configure()
runs - i would deem those as incomplete corresponding sources
which is a pretty clear FSDG no-no - i expect that very few GPL
programs follow that practice of web-as-dependency-management;
but the over-all gist of the FSDG is to extend the over-all gist
of the GPL to the entire "practical" system (and parabola extends
that further to apply to all files on the system)
if there is anything to discuss about that point, we should
defer that to the current mksource() discussion - interesting,
that both of these began as rather limited fixes for
design-bugs; and they both ended up knocking against the same,
much larger, concern of: "can users actually compile every
program using only the parabola source-balls" - if the network
must be active at build time, then cleaning the source-balls is
really quite futile
On Tue, 30 Jul 2019 22:28:16 -0300 Freemor wrote:
> As for the games/non-free assets downloading situation I
> personally feel that that is something better addressed with
> the existing blacklist (recommends-nonfree) or the like.
again though, the blacklist only works with pacman - the only way
to address that in abslibre, is to patch a whitelist into each
game or patch the downloaders out of them entirely
More information about the Dev
mailing list