[Dev] binary dependencies and blacklisting discussion (Was: repo redirector modificatoins)

Andreas Grapentin andreas at grapentin.org
Tue Jun 11 18:45:05 GMT 2019


On Tue, Jun 11, 2019 at 01:41:03PM -0400, bill-auger wrote:
> one new concern i would like to raise is regarding packages that
> are "not built from source" by the parabola standard - that is,
> specifically those the pull dependencies at build-time that are
> not itemized in the sources() array - this results in source
> incomplete packages

I think many of the java packages that build with maven could fall into
this category... It's a bit of a mess, last time I checked.

> even if disregarding the binary build deps, anything that is not
> itemized in the sources() array is something that may become
> unobtainable in the future (or in the case of pulling the the
> daily HEAD of a VCS repo, non-trivial to resolve which repo
> state corresponds to the original source, even if the source
> are obtainable) - that is aside from the concern that it
> requires the network to be active in build chroots
> 
> the proper solution, of course, is to package each of the sources
> separately, which adds a significant amount of work to the
> overall maintenance of the distro - that amount is roughly
> gauged by this value/cost metric:
> 
> where:
> 
>   value = n_users + importance
>   cost  = auditing + packaging + maintenance
> 
> the costs are not simple to guess, but do become evident by doing
> the work - auditing, although a relatively high cost, can
> probably be factored out; because that is entailed by each
> freedom bug report - value however is somewhat subjective,
> especially because we make no attempt to determine 'n_users',
> even proportionately - 'importance' is something that could be
> determined through some research and discussion; but it could be
> helpful for determining the fate of such packages like this, to
> start ranking packages by relative popularity (normalizing
> against something in 'base', such as 'pacman')
> 
> we dont want to blacklist anything hastily; but we also dont
> want to expend precious resources rescuing something that no one
> actually wants to use - most recently, certain packages such as
> 'dotnet' and 'lsd' have made this decision difficult
> 
> the 'awesome-terminal-fonts' package identified in the
> artistic-freedom bug report #2331, on its own, could probably be
> blacklisted as having a very low value/cost ratio; but that
> should also factor in the value/cost ratio of it's dependent
> 'lsd' package
> 
> https://labs.parabola.nu/issues/2331
> 
>   community/lsd 0.15.1-1
>     Modern ls with a lot of pretty colors and awesome icons
> 
> does any parabola user want such a thing, for example? - just
> because the devs may not value it, would not imply that users
> would not; so that is not a good gauge

I would suggest to get such a metric of cost vs. value, we could change
the way we blacklist packages. Instead of simply removing them from the
repositories, we could package a stub, that is just empty and has an
.inistall script that says something like this:

"this package is known to be nonfree because of REASONS. There is an
issue report here at URL, you can vote on this issue to let us know we
should be working on that, instead of playing dwarf fortress. Thanks!"

That way we could more liberally start blacklisting things, and get
immediate feedback from the community. Might even be able to automate
parts of that process.


-- 

------------------------------------------------------------------------------
my GPG Public Key:                 https://files.grapentin.org/.gpg/public.key
------------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20190611/bb1171be/attachment.sig>


More information about the Dev mailing list