Project

General

Profile

Bug #3248

Packaging Request #3208: [coreboot-util][libreboot-util]: Package ectool from coreboot for controlling the EC on coreboot and libreboot.

[nvramtool] conflicts with coreboot-util

wael - almost 2 years ago - . Updated almost 2 years ago.

Status:
duplicate
Priority:
bug
Assignee:
GNUtoo
% Done:

0%

Description

PKGBUILD needs to be updated to reflect that the packages conflict.
Maybe nvramtool can be even removed and just have coreboot-util be compiled for x86_64, i686 and armv7h.
I'm currently working on trying to get it to compile on the aforementioned platforms (i686 and armv7h are causing problems), so for the meantime it might be a good idea to add package conflicts.

History

#1

Updated by GNUtoo almost 2 years ago

  • Assignee set to GNUtoo

Hi,

I don't see coreboot-utils in Parabola i686. From which repository is it coming (aur? commuinty x86_64?).

The rationale behind doing this PKGBUILD the way I did is that Coreboot does contain nonfree software, for instance there is some nonfree AMD microcode in some files distributed in Coreboot source code.

So if we simply use Coreboot source code for packaging utilities, nonfree code will get redistributed by Parabola and all its mirrors as part of the package source.

But maybe it would be possible to make coreboot-utils use Libreboot source code instead. This way if we use we'd reuse the work being done for that and we would not redistribute nonfree code. Or if that's too hard to do we could at least add conflicts= in the nvramtool PKGBUILD.

#2

Updated by bill-auger almost 2 years ago

  • Related to Packaging Request #3208: [coreboot-util][libreboot-util]: Package ectool from coreboot for controlling the EC on coreboot and libreboot. added
#3

Updated by bill-auger almost 2 years ago

wael - what exactly is the "conflict" - that term has multiple meanings in this context - neither of these packages strictly conflict (per the conflicts=() array in the PKGBUILDs) - note that the 'coreboot-util' package includes the 'nvramtool' binary - that is probably the conflict, which the OP refers to - a file ownership conflict, not a package-level conflict

using libreboot as the upstream is a good idea - the small parts that wael wants to build are libre though - if the libreboot sources are not suitable; probably the unused coreboot source files can be deleted in a mksource() function - using libreboot would simplify that though

coreboot-util is only built for x86_64 - i686 does not compile - these are both very new packages - the 'coreboot-util' package is still a WIP; and it's ticket is still open - maybe the packages can be combined

#4

Updated by bill-auger almost 2 years ago

secondly, i should ask what is the rationale for putting nvramtool in [libre] - libre is mainly for blacklist replacements, and packages which are deemed to be essential to a parabola system or libre-tooling support - personally, i would like to put the latter set in a new [build-support] or [tooling] repo

#5

Updated by gap almost 2 years ago

pcr is the standard repo for new packages which don't fit into any other repo and are not essential or important enough to be considered part of the base system.

Should we consider nvramtool important enough to be part of the libre repo?
Since we haven't needed it until now and it is clearly a development tool, I think pcr is the best fit.

#6

Updated by wael almost 2 years ago

The conflict is because coreboot-util packages nvramtool anyway (conflict with /usr/bin/nvramtool), so there isn't much point in keeping it as a standalone package.
I thought about splitting the binaries into several packages, but I think that there is not much point in that when it is all just 4 binaries that are decently small.

#7

Updated by bill-auger almost 2 years ago

  • Parent task set to #3208
  • Status changed from unconfirmed to confirmed
#8

Updated by GNUtoo almost 2 years ago

Thanks for the link to the PKGBUILDs, I'll try to find the time to look at them.

It should be moved to pcr indeed. From the wiki1 there is some criteria for PCR. So we can deduce from it that PCR is for packages that both:

  • "are not included on official repos of Arch Linux"
  • "are not considered to be essential enough for the base system."

So it's not only for packages coming from Aur.

1 https://wiki.parabola.nu/Repositories#.5Bpcr.5D

#9

Updated by bill-auger almost 2 years ago

that is also how i understand it - PCR is not intended to be "AUR
replacements" like libre is "arch replacements"; because the AUR
is not a parabola upstream -

it was once considered to have a PUR as a replacement for the AUR
itself, for parabola users; but it was decided that there should
be no PUR - so PCR is an binary alternative to the PUR,
maintained by parabola team rather than users

#10

Updated by GNUtoo almost 2 years ago

  • Status changed from confirmed to duplicate

Thanks a lot for this bugreport, it made me learn about #3208 (work to add various Libreboot utilites to Parabola).

I'm now closing this bug since it makes more sense to handle this file path conflict in #3208 since #3208's PKGBUILD is not yet in Parabola.

#11

Updated by bill-auger almost 2 years ago

the 'coreboot-util' PKGBUILD is in abslibre - it was added about two weeks ago as pcr/coreboot-util

Also available in: Atom PDF