[Dev] Update on the PKGBUILDs license

Denis 'GNUtoo' Carikli GNUtoo at cyberdimension.org
Wed May 4 01:13:44 GMT 2022

On Mon, 2 May 2022 22:15:17 -0400
bill-auger <bill-auger at peers.community> wrote:

> On Mon, 2 May 2022 16:58:00 +0200 Denis wrote:
> > And then only 1 line with Maintainer, like that:  
> > > # Maintainer: Parabola hackers <this mailing list>  
> > Or like that:  
> > > # Maintainer: A specific parabola hacker <Mail>     
> i agree; but that would be a more significant break from the
> arch-like convention - it would complicate the diff/merging of
> most PKGBUILDs - i prefer to keep diffs as minimal as possible -
> to have only one Maintainer line, would eliminate the helpful
> hints "# Maintainer (arch):" which indicate where to find the
> upstream PKGBUILD to merge against
Do you have some workflow that would be broken from that? 

Personally I use meld for diffing PKGBUILDS and it doesn't create any

And if I need older PKGBUILDs to compare with I can get them with the
following method:
(1) I use git log to find the revision I'm interested in
(2) I use that revision to get the file hash like that:
    git ls-tree <revision> -- repo/package-name/PKGBUILD
(3) I then can get the file with the following command
    git show <hash> > PKGBUILD.old

Typically minimizing the diff that far is really important with
workflows that require to rebase on top of an upstream tree because it
avoids merge conflicts and enables automatic merges instead. So it
saves a lot of time.

But as I understand here doing that kind of workflows is not possible
with the current structure we have, though I could be wrong or it could
be something planned.

> On Mon, 2 May 2022 16:58:00 +0200 Denis wrote:
> > some might have compelling reasons to add them
> > as Maintainer instead of the Parabola project.  
> the most compelling reason, is that some PKGBUILDs are maintained
> by users - the Maintainer email address, exists for bug
> reporting - that would only work if we required all packagers to
> read the mailing list - i think that everyone in the keyring
> should be required to read the mailing list; but i dont think
> that was ever made as a matter of policy
I don't see the point here, the git history typically have the
information on who touches the file. So we have the email of the people
involved anyway, even if they forget to add the headers and so on.

If we have a line about Maintainers it should probably tell something
that the git history isn't telling.

Though that requires either people who are not official Parabola
hackers yet to send patches made with git format-patch or to
have people who merge that contribution to use --author when doing the
patch. But information on who touched the file can also be added in the
copyright headers anyway. In Guix every single person who touch a file
is supposed to add pers copyright header in that file. This simplifies
things a lot. 

In our case we could strongly require it for people that are not making
patches, and try to do it for people making patches that already have
the proper attribution because otherwise that information could be
completely missing or completely lost.

Anyway with copyright headers, having all the information there is also
useful in case people copy the PKGBUILD in other projects (like Aur for
instance) without the git history.

In that case the copyright information is kept in the new project which
is the way it's supposed to be done anyway, and it enables easier
sharing back and forth between several projects.

> the most compelling reason, is that some PKGBUILDs are maintained
> by users - the Maintainer email address, exists for bug
> reporting
> > It doesn't say "don't touch, only <maintainer> can modify it".  
> that is certainly in accordance with adhocracy; but in practice,
> some PKGBUILD maintainers complain when others modify the
> PKGBUILD significantly - i have only intervened in cases where
> the package in the repos is broken, _and_ users complain
> repeatedly, _and_ the maintainer does not respond to the bug
> reports - that really should not happen; but it does

And as I understand having a single person listed as maintainer means
that this person has some sort of authority over the packages and that
all the patches should go through that person and that at least other
people can't touch this package without that person's permission.

So if we add all the Parabola hackers as collective maintainers I
don't have any issue with that anymore because anyone included in that
collective can do modifications, review patches and so on.

This is more or less how it works with projects like Linux, u-boot,
Barebox and so on that have a MAINTAINER file with people listed as
maintainers inside that file. But nothing in these projects subsystems
(like DRM, sound, etc) from adding many maintainers and having
collective maintainership.

The issue I have here is that if there is a single maintainer, I think
it really needs to reflect the reality as it does push people not to do
anything or to send patch to that maintainer or not to touch the
package without the maintainer authorization.

I've only found that to be the with packages maintained by David P. /
megver83, and also for very short period of time for 1 package
I worked on as I had to finish work on a huge changes which then
made it way easier for anyone contribute to it later on.

As for if it's a good thing or not to have single maintainers If that
works for the person working on the package and for Parabola in general
I don't have any objections but it's not something to be taken lightly
so the default should rather be to have collective maintainership and
stating that in the header.

An issue slightly related to that would also be to think about long
term maintenance of packages. For instance if someone adds a package
and is then unable to maintain it and that users started to depend on
that it's not ideal. In another hand if users that want to use FSDG
compliant distributions cannot because the packages they depend on is
missing, it's not a good thing either.

An idea would be to give less guarantees on some repositories like PCR,
but that would also lead users to think that there is more guarantees
in libre for instance.

An issue with that is that some Arch Linux policies are probably far
from ideal, as in practice some Arch Linux packages for software that
is free software are not built from source. We can find list of
packages (that are known to be) affected by that in the blacklist

Java started to be way more problematic than before for instance as
the maven build system typically uses maven central, and in maven
central there are many "artifacts" without source code, with incomplete
source code, etc, so it's really a mess.

Some go packages also bundle a lot of dependency so knowing the license
is often a lot of work.

Since we are fixing that in Parabola (at least for Java), we could try
to upstream some of our work (and with the proper copyright headers it
could push Arch to adopt free licenses to clarify the copyright

> checking your email is easy - if a maintainer leaves a bug
> report open with no acknowledgement for more than a month; that
> suggests retiring that person from the "active" list;
>  then
> demoting the package to "team-maintained" - it is very easy to
> add people back when they do have sufficient time to be
> considered as "active" - in the real world that person would be
> reprimanded or fired
If that only affects "maintained" packages I'm OK with that. This way
if some people go on long holidays for some reasons, they would still
be Parabola hackers when they come back but their packages could be
maintained by other people in the meant time.

This also brings to knowledge again here: if that happens it would be
good to have at least some recommendations inside the PKGBUILD about
what to do or not to do for these new (temporary) maintainers. Else the
maintainer who is gone on holidays would find pers package completely
modified in the wrong way (according to that maintainer).

And in some cases we need to fix things fast anyway due to security
issues so packages also need to be buildable and fixable easily to not
to have to work on them the night in a hurry and burn out.
> that was perhaps drifting off-topic somewhat; but adhocracy
> should not excluded professionalism - there is much we could
> improve in that way; and i am sufficiently motivated recently, to
> start making such uncomfortable policy changes
For professionalism, I think the way to go is to pick up the parts that
are useful to us but not necessarily everything as some parts can
strongly limit volunteer based projects. And the useful parts can also
come from direct needs.

For instance clarifying things is good as it really helps contributors
and users. Respecting other humans is also something really important.

In both case we don't necessarily need to copy the industry to find
that out, and by doing it our way we also have the potential to do it
way better too. Though we need to be careful not to do it worse.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220504/4ac52be7/attachment.sig>

More information about the Dev mailing list