Re: [Dev] problems with replacements for blacklisted packages

2017-12-23 Thread Luke Shumaker 
On Fri, 22 Dec 2017 22:06:56 -0500,
Luke Shumaker wrote:
> > Luke Shumaker wrote :
> > >  - b43-fwcutter is not replaced by, but is provided by
> > >libre/b43-tools.  For one, I am flabbergasted that whatever freedom
> > >issues b43-fwcutter has aren't also issues with b43-tools.
> > >Secondly, b43-tools should probably replaces=(b43-fwcutter), or be
> > >renamed to b43-fwcutter.
> 
> I asked Emulatorman on #hyperbola
> 
> Rough timeline:
> 
>  - core/b43-fwcutter is only useful with non-free firmware
>  - core/b43-fwcutter is blacklisted because of the above
>  - openfwwf, a libre b43 firmware, is released
>  - Emulatorman packages libre/b43-tools for openfwwf, either not
>realizing that core/b43-fwcutter would work with openfwwf, or
>forgetting that core/b43-fwcutter ever existed.
> 
> The b43-fwcutter program in both packages is identical.  The
> difference is that b43-tools also includes other utilities like
> b43-asm.
> 
> So, what we should do:
> 
>  - unblacklist core/b43-fwcutter
>  - have libre/b43-tools provides=() and conflicts=() b43-fwcutter, but
>not replaces=()
>  - verify that openfwwf can be built with core/b43-fwcutter (that it
>doesn't need b43-asm or any of the other programs included in
>libre/b43-tools but not core/b43-fwcutter).
>* if it can:
>  - move b43-tools to pcr
>  - have openfwwf reference b43-fwcutter instead of b43-tools

openfwwf requires the b43-asm program to build; core/b43-fwcutter does
not provide that program; b43-tools needs to stay in [libre].

openfwwf does not depends on the b43-fwcutter program at all; it only
depends on other programs included in b43-tools.  The b43-fwcutter
program is not useful with openfwwf.

Therefore, we should
 - continue blacklisting core/b43-fwcutter
 - remove /usr/bin/b43-fwcutter from libre/b43-tools
 - do not include b43-fwcutter in any of libre/b43-tools' 
provides/conflicts/replaces

Emulatorman agrees with the above assessment.

 - perhaps mention the absence of b43-fwcutter in libre/b43-tools' pkgdesc

I have updated the documentation on the issue with b43-fwcutter on the
LibrePlanet list of software that does not respect the FSDG[1], as
well as in our blacklist.txt[2].  I have not yet updated the
libre/b43-tools package.

[1]: 
https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines#b43-fwcutter_.2F_b43-tools
[2]: 
https://git.parabola.nu/blacklist.git/commit/?id=c7ea5d453d6b3cf5e554c48707aa2e1b295c2f82

-- 
Happy hacking,
~ Luke Shumaker
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] problems with replacements for blacklisted packages

2017-12-23 Thread Luke Shumaker 
The following is a discussion of the semantics of
provides/conflicts/replaces.  It uses b43-fwcutter as an example, but
isn't about b43-fwcutter; it is written accepting the everything in my
previous email as accurate; which isn't true.  What we actually should
do is keep blacklisting core/b43-fwcutter, remove the
/usr/bin/b43-fwcutter program from libre/b43-tools, and have b43-tools
make no reference to b43-fwcutter in any of
provides/conflicts/replaces (perhaps note the absence of b43-fwcutter
in the pkgdesc).  But, in order to more directly and clearly address
Bill's points, I'm going to pretend that's not true, and that the
b43-fwcutter program is fine.

On Sat, 23 Dec 2017 02:05:08 -0500,
bill-auger wrote:
> On 12/22/2017 10:06 PM, Luke Shumaker wrote:
> >  - have libre/b43-tools provides=() and conflicts=() b43-fwcutter, but
> >not replaces=()
> 
> just to point out again what i learned from reading the archwiki on the
> topic of provides vs. conflicts vs. replaces that this suggestion is not
> in line with the original intention

It surely is in line with the original intention.  core/b43-fwcutter
provides the /usr/bin/b43-fwcutter program (and man page);
libre/b43-tools also provides that program, as well as a few others.

> 
> to re-iterate the semantics as the upstream describes it:
> * 'provides' - is used for dependency checking - multiple packages may
> 'provides' (and therefore satisfy) the same dependency and any number of
> them may be installed at the same time

If a program has b43-fwcutter as a dependency, it would be satisfied
by the version of /usr/bin/b43-fwcutter included in libre/b43-tools
(it is built from exactly the same sources as the version in
core/b43-fwcutter; `diff -r` says so).

> * 'conflicts' - is used for conflict resolution - at most one
> conflicting package may be installed at any time - if you try to install
> a conflicting package then the package manager will ask to remove the
> one that is installed

Both core/b43-fwcutter and libre/b43-tools include the file
/usr/bin/b43-fwcutter; they cannot both be installed at the same time.

> * replaces - is the important one for this discussion - according to the
> docs, when any new package is added to the repo that states that it
> 'replaces' another, it has the definite, immediate, and specific effect
> of forcefully removing the specified package from any user's system, and
>  without asking (i think), and replacing it with the new replacement
> package - this happens the next time that the user `pacman -Syu` and it
> may even ignore any "hold" on the old package

Pacman will prompt "Replace A with B? [Y/n]:".  This can be disabled
by adding the replacement to IgnorePkg in pacman.conf.

>   - this was intended to be
> used only for emergencies if, for example, some malware got into the system

This isn't only for emergencies.  It is used whenever one package is
dropped in favor of another package (perhaps just a package rename).
When eigen3 got renamed to eigen, eigen now replaces=(eigen3).  When
libdbus got merged in to the dbus package, dbus now replaces=(libdbus)
because otherwise -Syu wouldn't upgrade it for a user who had libdbus
installed, but not dbus; they'd silently end up with an old libdbus
package (it would show up in `pacman -Qm` though).

If we wanted drop core/b43-fwcutter from our repos (blacklist it),
then libre/b43-tools *should* replaces=() it because we are dropping
one implementation of /usr/bin/b43-fwcutter for another, and the new
one should replace the old one.

One way of looking at it is that provides=() and conflicts=() affect
all users, while replaces=() only affects *upgrades*, not *new
installs*.

> again im not saying that breaking convention is bad but if the package
> manager has these specific behaviors triggered by these lists care must
> be taken to ensure that the new semantics have no unintended practical
> side-effects
> 
> if the suggestion here is for parabola to use the 'replaces' attribute
> for some purpose other than what is described above it may be instead a
> better idea to introduce a new list such as: 'libre_replaces=()' that
> pacman will ignore

We do use replaces=() for the intended purpose.  A user migrating from
Arch should be asked "Replace linux with linux-libre?", "Replace
firefox with iceweasel?"  From the user's/pacman's perspective,
upstream dropped linux in favor of linux-libre; that's exactly what
replaces=() is for.

-- 
Happy hacking,
~ Luke Shumaker
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] problems with replacements for blacklisted packages

2017-12-22 Thread bill-auger 

On 12/22/2017 06:05 PM, Isaac David wrote:
> the idea is to get rid of replacement info in blacklist.txt

to this i want to add again that this single line  of explanation in the
blacklist.txt is in most cases the only documentation of why the package
is blacklisted and what are the remedies - so this would make it even
more imperative that the blacklisting process be fully documented


On 12/22/2017 10:06 PM, Luke Shumaker wrote:
>  - have libre/b43-tools provides=() and conflicts=() b43-fwcutter, but
>not replaces=()

just to point out again what i learned from reading the archwiki on the
topic of provides vs. conflicts vs. replaces that this suggestion is not
in line with the original intention - not to say that it is necessarily
a bad thing but when making a break from convention it is wise to be
aware that it is a break from convention - e.g. the semantics of
provides vs. conflicts vs. replaces in any packages from upstream are
different from how parabola uses those lists - but more importantly that
these are not intended to be informational in the way being described
here - these attributes are functional and trigger specific behaviors in
the package management tools

to re-iterate the semantics as the upstream describes it:
* 'provides' - is used for dependency checking - multiple packages may
'provides' (and therefore satisfy) the same dependency and any number of
them may be installed at the same time
* 'conflicts' - is used for conflict resolution - at most one
conflicting package may be installed at any time - if you try to install
a conflicting package then the package manager will ask to remove the
one that is installed
* replaces - is the important one for this discussion - according to the
docs, when any new package is added to the repo that states that it
'replaces' another, it has the definite, immediate, and specific effect
of forcefully removing the specified package from any user's system, and
 without asking (i think), and replacing it with the new replacement
package - this happens the next time that the user `pacman -Syu` and it
may even ignore any "hold" on the old package - this was intended to be
used only for emergencies if, for example, some malware got into the system

again im not saying that breaking convention is bad but if the package
manager has these specific behaviors triggered by these lists care must
be taken to ensure that the new semantics have no unintended practical
side-effects

if the suggestion here is for parabola to use the 'replaces' attribute
for some purpose other than what is described above it may be instead a
better idea to introduce a new list such as: 'libre_replaces=()' that
pacman will ignore



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] problems with replacements for blacklisted packages

2017-12-22 Thread Luke Shumaker 
On Fri, 22 Dec 2017 17:37:03 -0500,
Isaac David wrote:
> Luke Shumaker wrote :
> >  - b43-fwcutter is not replaced by, but is provided by
> >libre/b43-tools.  For one, I am flabbergasted that whatever freedom
> >issues b43-fwcutter has aren't also issues with b43-tools.
> >Secondly, b43-tools should probably replaces=(b43-fwcutter), or be
> >renamed to b43-fwcutter.
> 
> i'm scratching my head over this too. their respective PKGBUILDs
> aren't like each other, but where does b43-tools even come from? it's
> not in the AUR.
> 
> [1]: 
> https://git.parabola.nu/packages/libretools.git/commit/?h=isacdaavid=313d1ee619363eca0b8b0742a2d58c9ce18877fd
> [2]: https://lists.parabola.nu/pipermail/dev/2017-October/005936.html

I asked Emulatorman on #hyperbola

Rough timeline:

 - core/b43-fwcutter is only useful with non-free firmware
 - core/b43-fwcutter is blacklisted because of the above
 - openfwwf, a libre b43 firmware, is released
 - Emulatorman packages libre/b43-tools for openfwwf, either not
   realizing that core/b43-fwcutter would work with openfwwf, or
   forgetting that core/b43-fwcutter ever existed.

The b43-fwcutter program in both packages is identical.  The
difference is that b43-tools also includes other utilities like
b43-asm.

So, what we should do:

 - unblacklist core/b43-fwcutter
 - have libre/b43-tools provides=() and conflicts=() b43-fwcutter, but
   not replaces=()
 - verify that openfwwf can be built with core/b43-fwcutter (that it
   doesn't need b43-asm or any of the other programs included in
   libre/b43-tools but not core/b43-fwcutter).
   * if it can:
 - move b43-tools to pcr
 - have openfwwf reference b43-fwcutter instead of b43-tools

-- 
Happy hacking,
~ 
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] problems with replacements for blacklisted packages

2017-12-22 Thread Luke Shumaker 
On Fri, 22 Dec 2017 17:37:03 -0500,
Isaac David wrote:
> 
> Luke Shumaker wrote :
> > I wrote a little pyalpm script for finding blacklist replacements (as
> > in the second column in blacklist.txt).
> 
> cool. i'm eager to compare it against the one i wrote for
> libreblacklist using expac.[1][] i'm hoping that we will
> move forward with the idea sketched in [2][].
> 
> from your observations it seems that yours is doing more than just
> finding replacements, like delving into pkgbase and splits, and
> checking for accompanying provides=().
> 
> [1]: 
> https://git.parabola.nu/packages/libretools.git/commit/?h=isacdaavid=313d1ee619363eca0b8b0742a2d58c9ce18877fd
> [2]: https://lists.parabola.nu/pipermail/dev/2017-October/005936.html

https://git.parabola.nu/blacklist.git/commit/?id=d13133aec0060f975c410bd95156ad9369e80188

It works very similarly to your expac version.  The expac one looks at
pkgname, replaces, and provides; mine looks at pkgname and replaces
only, but if there are 0 pkgname/replaces matches, *then* it falls
back to looking at provides as "suggestions".

It has a very similar list of caveats to the expac one:

 - It shows all replacements (comma-separated), rather than just one.
   By grepping for comma, I identified packages with multiple
   replacements, which I consider to be an error.

 - It uses the repos on the system, configured in pacman.conf

 - Replacements are show as repo/pkgname, rather than just pkgname.
   By grepping for lines that don't contain "libre/" or
   "libre-multilib/", I identified packages that should be moved to
   [libre], as well as identifying variants of non-free packages from
   Arch that aren't blacklisted ("community/tensorflow-opt" showing up
   as a suggested replacement for tensorflow).

-- 
Happy hacking,
~ Luke Shumaker
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] problems with replacements for blacklisted packages

2017-12-22 Thread Isaac David 

Megver83 wrote :

let's say we blacklist linux and linux-docs/linux-headers are
automatically blacklisted. All right up to there, but where do we
specify that linux-headers' replacement is linux-libre-headers? (same
for -docs)


in the PKGBUILD, as is currently done.

the idea is to get rid of replacement info in blacklist.txt, and allow
your-freedom to query the repos to know what it should and shouldn't
conflict with.

--
Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
Ring: c8ba5620e080bef9470efb314c257304ff9480f5
Tox: 
0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C



___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] problems with replacements for blacklisted packages

2017-12-22 Thread Isaac David 

Luke Shumaker wrote :

I wrote a little pyalpm script for finding blacklist replacements (as
in the second column in blacklist.txt).


cool. i'm eager to compare it against the one i wrote for
libreblacklist using expac.[1][] i'm hoping that we will
move forward with the idea sketched in [2][].

from your observations it seems that yours is doing more than just
finding replacements, like delving into pkgbase and splits, and
checking for accompanying provides=().


I'll be polishing it up and committing it soon, but it did identify a
few problems/concerns.

 - unrar is replaced by both libre/unar and pcr/gna-unrar.  libre/unar
   should drop the replaces=(unrar) line, and pcr/gna-unrar should be
   moved to libre.


you packaged pcr/gna-unrar :)


 - tensorflow has several other versions that are not blacklisted:
   tensorflow-opt and tensorflow-opt-cuda.  I think that this is an
   argument toward prioritizing switching to pkgbase-based
   blacklisting.


sounds practical from a your-freedom perspective, but it will require
that dbscripts learns how to expand pkgbase for a given Arch
package, or something like that.

i'm thinking of the import script specifically: there's one entry per
pkgname in the databases, and pkgbase only exists as metadata IIRC.
keeping the specificity might be more practical in the end.


 - b43-fwcutter is not replaced by, but is provided by
   libre/b43-tools.  For one, I am flabbergasted that whatever freedom
   issues b43-fwcutter has aren't also issues with b43-tools.
   Secondly, b43-tools should probably replaces=(b43-fwcutter), or be
   renamed to b43-fwcutter.


i'm scratching my head over this too. their respective PKGBUILDs
aren't like each other, but where does b43-tools even come from? it's
not in the AUR.

[1]: 
https://git.parabola.nu/packages/libretools.git/commit/?h=isacdaavid=313d1ee619363eca0b8b0742a2d58c9ce18877fd

[2]: https://lists.parabola.nu/pipermail/dev/2017-October/005936.html

--
Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
Ring: c8ba5620e080bef9470efb314c257304ff9480f5
Tox: 
0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C



___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] problems with replacements for blacklisted packages

2017-12-21 Thread Megver83 
El 21/12/17 a las 03:22, Luke Shumaker escribió:
> Hi guys,
> 
> I wrote a little pyalpm script for finding blacklist replacements (as
> in the second column in blacklist.txt).
> 
> I'll be polishing it up and committing it soon, but it did identify a
> few problems/concerns.
> 
>  - unrar is replaced by both libre/unar and pcr/gna-unrar.  libre/unar
>should drop the replaces=(unrar) line, and pcr/gna-unrar should be
>moved to libre.
> 

+1

>  - tensorflow has several other versions that are not blacklisted:
>tensorflow-opt and tensorflow-opt-cuda.  I think that this is an
>argument toward prioritizing switching to pkgbase-based
>blacklisting.

I agree, for example the 'linux' package from arch is an split package
which compiles 'linux', 'linux-headers' and 'linux-docs'. Although it
might make difficult to specify its replacement.

I mean, let's say we blacklist linux and linux-docs/linux-headers are
automatically blacklisted. All right up to there, but where do we
specify that linux-headers' replacement is linux-libre-headers? (same
for -docs)

> 
>  - b43-fwcutter is not replaced by, but is provided by
>libre/b43-tools.  For one, I am flabbergasted that whatever freedom
>issues b43-fwcutter has aren't also issues with b43-tools.
>Secondly, b43-tools should probably replaces=(b43-fwcutter), or be
>renamed to b43-fwcutter.

Did not know about this.

> 
>  - Why does linux-libre-pck provide linux-zen?  Replacing it (which it
>doesn't do) makes a little bit of sense, but providing it makes no
>sense to me.

The Parabola Community Kernel *has the linux-zen patch* (which has BFQ,
BFS and gracy's gcc kernel patch) plus a few others (as of now, apart
from ZEN, it has TuxOnIce, UKSM and AUFS). So technically it does
replace and provides linux-zen since, as I said, ZEN is one if the
patches from PCK.

> 
>  - What's the deal with pcr/mesa-vanilla replacing a bunch of nvidia
>stuff?  It seems that mesa-vanilla is unmaintained since
>emulatorman and coadde left, we should just drop it?

We should look for packages that depend on it. If there aren't, I don't
see why not removing it.

> 
>  - The following packages are on pcr, but should be moved to libre:
>figlet, mplayer-vaapi
>  
> 
-- 
~Megver83

SIP: megve...@sip.linphone.org
XMPP: megve...@jabjab.de
Tox: megve...@toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megve...@quitter.cl
Diaspora*: megve...@diasp.org
Matrix: @Megver83:matrix.org



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev

Re: [Dev] problems with replacements for blacklisted packages

2017-12-20 Thread bill-auger 
i do not know the answer to any of those questions but it is good that
you looked into it so thoroughly - one thing i have been recommending
for is to ensure that each blacklisted or replaced package has some
meaningful description noting (however tersely) some rationale as to why
it was originally declared to be the non-free status that it has and how
any libre replacements address the issue



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev