the most recent octopi package package, introduced a PKGBUILD with many policy issues, low-quality PKGBUILD, and a loss of important functionality (probably _the_ most desired functionality of this package - the notifier applet) package)

i started looking at this package because for some reason, the new package ended up in libre; so it did not replace the existing PCR package - im not sure how that happened, but i fixed that - this is an important package for the GUI LiveISOs, so i wanted to check it out thoroughly - once i started looking at the PKGBUILD, i found so many "nit-picky" things which bothered me, that i am opening this ticket to list them all - most of these notes are non-functional non-functinal housekeeping issues; but we should correct them

there are multiple policy issues with the AUR PKGBUILD

* GUIDELINE: "Do not add $pkgname to PKGBUILD#provides, as it is always implicitely provided by the package."
- provides=('octopi' 'octopi-repoeditor' 'octopi-cachecleaner')
- conflicts=('octopi') # <- conflicts with itself?
* GUIDELINE: "add a comment ... which contains information about the ... previous contributors"
- acknowledgments acknowlegements of all previous contributors were deleted
* GUIDELINE: "under /usr/share/licenses/common/. If a package is licensed under one of these licenses, the value should be set to the directory name, e.g. ... (L)GPL — (L)GPLv2 or any later version
- this program is GPLv2 or any later version - the license=('GPL2') should be 'GPL'
* GUIDELINE: "Do not create duplicate packages."
- duplicate packages in [libre] and [pcr]
* GUIDELINE: "Suffix pkgname with ... -git etc. unless the package fetches a specific release."
- the PKGBUILD violates two different packaging guidelines on this issue
- it builds from an arbitrary git commit, not the versioned upstream release (as it did for previous versions)
- an 'octopi-git' PKGBUILD already existed, when this change was done, and it still does - that one is on the AUR maintainer though, not our problem; because parabola avoids -git packages

i understand the value of keeping the diff small; but we should not keep parts which are unnecessary unnecceray or incorrect, even if it were an arch package - if housekeeping changes make the diff too messy, then someone should contact the maintainer to maintainer, and try getting the corrections upstreamed

h2. lost functionality:

* does not install a .desktop file for the octopi-repoeditor program

* does not build the octopi-notifier program
- this is needed for the liveISOs
- again, thats fine for now; but it needs to be be fixed before new GUI ISOs are made
- the upstream documentation says that the notifier program asks to install AUR helpers - AFAIK, previous versions did not suggest that - this needs investigating and possibly patching

h2. problems that it had before, and still does now:

* the license=('GPL2') should be 'GPL'

* does not install the pacman install hook: octopi.install
- this is included in the upstream sources to seed the database upon install; but it looks like parabola never installed it
- the systemd service file which the install hook would enable, does get installed however - unfortunately the user would most likely never know that it exists, without an .install hook, or a wiki article to suggest starting the service
- thats fine for now, because the install hook is systemd-specific; but it could (maybe even should) be fixed, and an openrc service file be made fixed

* the ", without nonfree AUR things" appendage to pkgdesc is not needed for PCR packages - i specify those technical differences only for nonprism and nonsystemd packages
- that distinction would make perfect sense if this were another AUR PKGBULD, or if this were a libre replacement for a non-FSDG arch package; but the parabola 'octopi' package is neither
- i dont think we need whenever a pkgdesc is appended in that way, it should indicate a libre replacement on the blacklist; because it raises questions as to specify those technical differences for libre replacements either why that modification was made
- libre replacements should have an associated freedom bug report for future reference and comments, and a "parabola changes and rationale:" comment in the PKGBUILD; but PCR packages usually have neither
- IMHO, that is a package in PCR does not need special explanation to document the proper place rationale _why_ it was modified; because it was not modified - it does not need to mention changes distinguish it from a corresponding non-FSDG package, because no non-FSDG package exists

h2. problems that it did not have before, that it does now:

* it has both a pkgbase and pkgname, with the identical names, and is not a split package
- pkgbase is completely useless and meaningless for this PKGBULD

* has unsatisfiable optdepends=('octopi-notifier-qt5' 'octopi-notifier-frameworks')
- these can both be built from the same sources as octpoi; but as noted above, neither are built
- at least one of these should be built for parabola
- they are apparently mutually exclusive; so if they both are needed, 'octpoi' should be made into a split package again


* builds from an arbitrary git commit, rather than the versioned release tag
- when this is done, the package name should end with -git
- parabola PKGBUILDs should use versioned releases, for every upstream which has versioned releases

* provides 'octopi' (although nothing else does) and conflicts with 'octopi' (which is only itself)
- its not clear what this was intended to accomplish; but the arch packaging guidelines prohibit it explicitly
- it also provides 'octopi-repoeditor' and 'octopi-cachecleaner', which no other parabola or AUR package requires
- there once were separate packages for 'octopi-cachecleaner', and 'octopi-repoeditor' - that was over two years ago - those package names are meaningless to parabola now

* the AUR maintainer added i686 to the arch=() array - the diff could be minimized by adjusting it
- the AUR PKGBUILD:
arch=('i686' 'x86_64')
- the parabola PKGBUILD:
arch=('x86_64')
arch+=('i686' 'armv7h')

there are several thing about the list of contributors, which bother me - i may write to the mailing list for discussion about that instead; because they apply to all PKGBUILD genrally