#613 "provenpackagers" tag
Closed: nothingtodo 5 years ago Opened 6 years ago by zbyszek.

Continuation of https://fedorahosted.org/fesco/ticket/1562.
Also see the discussion in https://meetbot.fedoraproject.org/fedora-meeting/2016-04-01/fesco.2016-04-01-17.00.log.html.

== Background ==

There's a number of packages "closed" to provenpackagers, through three different mechanisms:

  1. provenpackagers cannot commit (​https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages says: As an exception, some specific packages can be closed to provenpackagers, upon FESCo approval.)". This applies to firefox, xulrunner, thunderbird. The motivation is trademark issues.

  2. provenpackagers can commit but the build will not be taggged (kernel, shim, grub2). Those packages are used in secure boot and builds require special signatures.

  3. some packages maintain their spec upstream and just overwrite any local fedora changes. Changes there should be coordinated with them. Includes anaconda, cockpit, fedora-release, fedora-repos, initscripts, probably others.

In order to unify handling of those cases (and possibly remove exception 1), a standarized comment in the spec file could be used to warn provenpackagers.

== Proposal ==

Define a "tag" to be included in the spec file that would declare that there are special considerations for the modifications in that package:

provenpackagers: maintained externally
provenpackagers: secure boot
provenpackagers: trademarks

With the following meanings:
"mainted externally" means that the changes might be lost. For example it's fine to do an rebuild, but the changelog entry might be lost.

"secure boot" means that changes are possible, but a build cannot be performed.

"trademarks" means that significant modifications to the code, meaning patches, require trademark approval, but small changes are OK.

Both the tag and possible rhs values would be standardized to allow easy automatic processing.

From the FESCO ticket:

In fact I have no idea how to discover the list of packages...

Out of curiosity, what is your use-case? (What do you intend to do with this list of packages, once you have it?)

Nothing ;) My point was that there's some special list, with some scant documentation, and we should kill it unless it's actually useful. Look at this from the POV of a new packager: Fedora is a giant bureaucracy with hundreds of written and unwritten rules, and written rules which are ignored, etc. When we don't keep trimming old stuff, we have to pay for the mental overhead.

I don't see the point either, are proven packagers changing some of these packages and then being surprised?

Certainly, at least for case 3. For the other two... maybe, hard to say without asking around.

The idea is to drop the permission setting, and instead only have the tag in the spec file.

There are people who have changed some of these packages and caused issues:

  • I think there have been some people who have commited to the kernel and tried to build it and gotten confused when it failed.

  • I know some folks have tried to add patches to things that are maintained elsewhere and had their changes overwritten (anaconda, lvm2).

Also, tibbs was talking about mass changing things like removing defattr or other useless kruft, but it would be helpfull to know which packages to exclude from such a automated culling.

Is there any update here?

I think this is waiting for evaluation by FPC. Comments #2 and #7 should answer the questions that have been asked so far.

For the record, I'm a strong +1 that it should be a guideline that packages where the spec is also tracked in some external SCM must clearly indicate this somehow, and have a reasonable mechanism for reconciling changes.

Metadata Update from @kevin:
- Issue assigned to zbyszek

5 years ago

I've already said most of this on the mailing list, but for FPC's record:

I'm definitely for labeling "special" specs somehow, probably with just a comment on the first line with a few prescribed characters followed by a mandatory explanation. This should apply for any spec which has something that a maintainer would really need to know before they made changes. I understand that some packages can be fragile or have long dependency chains which might preclude simple packaging work.

However, I would be strongly against anything which gives anyone the idea that it is remotely acceptable to have the Fedora spec not be canonical. That's simply not a supportable case. I would to move more towards automatic package cleanup, and there's been talk of automatic dependency tree rebuilds in rawhide, both of which could auto-change a large number of packages and both of which simply require that the Fedora spec be the "master".

Metadata Update from @tibbs:
- Issue close_status updated to: None
- Issue tagged with: meeting

5 years ago

Ceph is another one where we maintain the .spec file in the upstream project in GitHub, so I'm interested in this too.

I tossed out a very early draft in https://fedoraproject.org/wiki/User:Tibbs/SensitiveSpecs

A live diff is at https://fedoraproject.org/w/index.php?title=User%3ATibbs%2FSensitiveSpecs&diff=latest&oldid=486601

The changes are near the top in the section relating to spec files: https://fedoraproject.org/wiki/User:Tibbs/SensitiveSpecs#Spec_Files

I took out some stuff which really didn't belong in the guidelines to make room for the new subsection. There is certainly more to clean up in there which isn't directly related to this ticket and which I will do separately.

The list of tags I came up with is purely a random set of things I threw out so that I could have something there.

Metadata Update from @tibbs:
- Issue assigned to tibbs (was: zbyszek)
- Issue tagged with: hasdraft

5 years ago

I personally like this, but I think it'd be a good idea to discuss with the folks (especially RH teams...) who are using this pattern and see if this is too heavy for them. The cases I'm aware of besides ceph are anaconda - https://github.com/rhinstaller/anaconda/blob/master/anaconda.spec.in - and productmd - https://github.com/release-engineering/productmd/blob/master/python-productmd.spec .

Works for me.

(Now the second step would be to make sure that such packages are rare, but let's first see how many there actually are.)

Do keep in mind that nothing we do in packaging guidelines is going to ever be able to force any team to do anything differently. But Fedora needs to be able to assume that Fedora's specs are actually Fedora's. I really want to do more package cleanup, and much of it will be automated. It's not going to be feasible to tiptoe around every workflow that someone has cooked up.

Still, what's the worst that ever happens? They write over Fedora changes and the release number goes backwards or their package fails to build? They'll find out about that pretty quickly.

In any case, the guideline merely says that they must be prepared to merge Fedora changes back. Surely they'll know when changes happen on the Fedora side (via notifications and such) and of course git can trivially show that. So, really, all this does is act to cut off complaints when the Fedora community actually functions as a community in package maintenance.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2017-02-23/fpc.2017-02-23-17.00.txt):

Metadata Update from @james:
- Issue untagged with: hasdraft, meeting
- Issue tagged with: writeup

5 years ago

Written up. Announcement text:

The section of the guidelines relating to spec files was reorganized. Outdated information was removed and a new section was added indicating the canonical status of the spec file in Fedora git repository.
* https://pagure.io/packaging-committee/issue/613

Metadata Update from @tibbs:
- Issue untagged with: writeup
- Issue tagged with: announce

5 years ago

Note that this isn't done; we still have to deal with whether we want to mark "special" packages somehow, and the actual mechanics of that.

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

5 years ago

We discussed this at last weeks meeting, and decided there was nothing more to do:


Metadata Update from @james:
- Issue close_status updated to: nothingtodo
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.