#691 guidelines change: noarch *sub*packages with arch-specific dependencies
Opened 2 years ago by praiskup. Modified 9 months ago

Guideline page needing clarification:

https://fedoraproject.org/wiki/Packaging:Guidelines (paragraph: Noarch with Unported Dependencies)

Explanation

According to [1] some noarch packages will be dropped from Fedora because some sub-packages' arch-specific deps can not be satisfied on (pretty newly added) architectures in Fedora.

Solution suggested by Till (in [1]) should be "legalized" in guidelines, so I propose:

Arch-Specific Runtime Dependencies in sub-packages
--------------------------------------------------

Sometimes noarch package has dependency on arch-specific package that can
not be satisfied on particular architecture.  Such package is automatically
retired and removed from Fedora.

You might either use the ExclusiveArch work-around from 'Runtime
Dependencies' paragraph, so the entire package (including sub-packagees) will be
provided only in ExclusiveArch architectures.

Alternatively the noarch package can be made arch-specific (by not using
BuildAarch: noarch) and then %ifarch/%ifnarch macros might be used to avoid
building of concrete sub-packages on concrete architectures.

[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6CZUFQZKUVWPOMXNILQDHGZK7XCUXCSN/


Thank you for working on improving the guidelines. I agree that documenting the other workaround is good idea. The retirement procedure needs to be documentend in the release engineering docs. The packaging guidelines are not the place for this. They describe the technical facts about packaging. I tried to write an addition that includes a little bit more detail about the situation as I understand it. I propose to add it to the section about unported runtime dependencies:

{{admon/important|No Subpackage Support| The <code>ExclusiveArch</code> workaroud only works if your package does not generate any subpackages. If only some subpackages depend on an unported package, you need to make the package architecture dependent and use <code>%ifarch/%ifnarch</code> macros to enable/disable the respective subpackages. Do not forget to disable the debuginfo package with <code>%global debug_package %{nil}</code> when making a package architecture-dependent. If the main package is architecture-dependent and is not built for all architectures, the subpackages cannot be noarch if they depend on the main package. Then they need to be architecture-dependent as well.}}

Thanks for working on it.

The retirement procedure needs to be documentend in the release engineering docs. The packaging guidelines are not the place for this.

Agreed that we should edit both guidelines and rel-eng docs.

The ExclusiveArch workaroud only works if your package does not generate any subpackages.

IIRC it actually works, but it removes the main package including all sub-packages.

I'm not sure what state this proposal is in currently. It is just down to the admon that @till wrote?

I'm not sure that workaround even actually works in practice due to the problem that you can't control which builder you get, but I recall seeing a patch to koji get accepted relatively recently which makes that work. If so, once that gets into Fedora infrastructure then we should document it as a more acceptable solution.

Finally, that link goes to a massive thread; I have no idea which individual suggestion you are linking to.

Metadata Update from @tibbs:
- Issue tagged with: meeting

2 years ago

I'm not sure what state this proposal is in currently. It is just down to the admon that @till wrote?

Yes it is the admon. Generally speaking it is about documenting that a package needs to be arch-dependent when it uses sub-packages and has unported runtime dependencies. Also it is about documenting about how to handle the case that only some sub-packages have unported runtime dependencies on some architectures.

I'm not sure that workaround even actually works in practice due to the problem that you can't control which builder you get, but I recall seeing a patch to koji get accepted relatively recently which makes that work. If so, once that gets into Fedora infrastructure then we should document it as a more acceptable solution.

Good catch, The workaround already worked for unported runtime dependencies if the package does not have any subpackages. It might also work in some cases when there are subpackages but I believe I saw at least one case where it did not work when the main package was arch-dependent and a subpackage was noarch. I will check this.

The koji patch ( https://pagure.io/koji/c/55d57495 ) is already deployed on the Fedora buildhosts afaik and now allows to use the workaround also for build dependencies. This means that you made me aware that the section "Arch-Specific Build-Time Dependencies" is now outdated in the packaging guidelines. I believe if there are only unported build-time dependencies the workaround (BuildArch: noarch with ExlusiveArch: ... ) now works in all cases.

Another issue I just became aware is that the Guidelines are missing a statement when to actually use noarch. It currently says "Content, code which does not need to compile or build, and architecture independent code (noarch) are notable exceptions." I have to think about a concrete proposal for this and will propose one later.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2017-06-22/fpc.2017-06-22-10.00.txt):

  • x#691 noarch subpackages with arch-specific dependencies (geppetto,
    16:06:19)

We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2017-06-28/fpc.2017-06-28-17.13.txt):

  • x#691 noarch subpackages with arch-specific dependencies (geppetto,
    17:19:38)
  • First problem is that we should warn people that the trick of using
    Excludearch in a noarch package only works when you have no
    subpackages. (geppetto, 17:24:04)
  • Second problem is a koji change means we need other changes.
    (geppetto, 17:24:44)
  • ACTION: We need to ask someone in releng what policy should be and
    then write a draft (geppetto, 17:27:06)

I wonder if there's any way we can move this forward. We did make some changes recently regarding ExclusiveArch: and noarch together, but that wasn't about subpackages.

Unfortunately I haven't had much luck getting real answers; I think the bottom line is that nobody really knows what koji is supposed to do in any of these situations. We can look at the code and see how it's supposed to work, but really what's needed is for someone to actually try all of the relevant cases, document them, and then both report bugs as necessary and make sure nothing in our guidelines contradicts reality. And all of this needs to be done live in rawhide, so that we exercise the complete path through the system. (Unless someone can think of another way to test the whole stack, of course.)

I can say up front that I do not have the time to do this, but that it would be really nice if someone did.

Metadata Update from @churchyard:
- Issue assigned to churchyard

10 months ago

We spoke about this ticket in last weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-05-03/fpc.2018-05-03-16.01.txt):

  • x691 noarch subpackages with arch-specific dependencies (geppetto,
    16:08:48)
  • ACTION: mhroncok Will open a releng ticket to see if they know the
    answer to the koji questions. (geppetto, 16:21:05)

Metadata Update from @churchyard:
- Issue untagged with: meeting
- Issue tagged with: needinfo

9 months ago

Login to comment on this ticket.

Metadata