[Dev] [Votation] Package freedom guidelines, what to do next

[Michał Masłowski]

> I like guidelines that propose mtjm to our distro, but i think that
> could to put a rule about to put "-libre" variation on our libre
> packages too.

This can be decided completely separately from the other rules.

> Eg: we have some packages with $pkgbase-$pkgname-libre,
> other with $pkgbase-libre-$pkgname or without "-libre". I think that
> should to put a rule when is necessary to put "-libre" in the package
> and the position about it, because i had problem and doubts about put
> -"libre" as $pkgbase-libre-$pkgname or $pkgbase-$pkgname-libre due that
> we don't have rules for it.

I think this procedure would give similar results to what we have:

1. If the exact package name is needed, keep it.
2. If we change upstream "a" to "b", change "a" to "b" in the name.
3. If there is no "-libre" in the resulting name and the package of the
   current upstream is changed for the FSDG/Parabola freedom guidelines,
   append "-libre".

Examples:

filesystem -> filesystem
linux -> linux-libre
linux-tools -> linux-libre-tools
firefox -> icecat, iceweasel-libre
p7zip -> p7zip-libre
gnustep-make -> gnustep-make (no freedom-related changes; obsolete example)

(I don't know any cases of packages having "libre" in their names before
2.)

I.e. we would get "a-libre-b" only if the package name as "c-b" and the
upstream "c" was changed to "a-libre" (or "c-b" to "a-libre").

However, changing package names introduces some problems:

- it's not obvious when rule 1 should be used
- updates are considered removals and installs, so pacman will mishandle
  configuration files and maybe consider dependencies unsatisfiable
- adding correct provides and conflicts is needed
- pacman won't automatically update the package to the fixed, updated
  and unblacklisted non-libre-suffixed package from Arch: users will ask
  how to fix the old package bitrotting or report systems not booting
  due to a missing manual update
- it's against the (imo meaningless) KISS principle which we refer to in
  our promotional materials

(Not all of these problems are worthy of solving.)

The only argument for adding "-libre" that I know is making users know
that the package was changed for freedom reasons; I believe these
resources could solve this problem effectively:

- package descriptions
- packages being in [libre] instead of other repos

Therefore I support using the following procedure for new packages:

1. If we change upstream "a" to "b", change "a" to "b" in the name.
2. If the resulting package cannot be used instead of the original
   package, change its name so users will know this and other packages
   won't use it.

(There is no benefit from renaming existing packages again to use this
rule, while it would have all problems of the original rename.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/4553eebd/attachment.sig>