Since the actual draft is just a single sentence, I'll save everyone the of clicking and just paste it here:

If FESCo has agreed to deprecate a package that this package depends on then the submitter SHOULD submit an issue to the upstream to avoid that dependency and MUST add a bugzilla ticket blocking the tracking bug for that deprecation so it can be tracked.

Some comments:

• Mentioning "submitter" makes me think this was intended as a review guideline. We should try to avoid that kind of thing in the main guidelines. (Though there are probably some still in there.)
• How is someone supposed to know that a package is deprecated? Surely you can't expect someone to go through the entire dependency tree and check to see if there's a bugzilla ticket open relating to deprecation.
• We need to use a tracking mechanism for deprecated packages. Maybe even just Provides: deprecated would work. Then we can just say that you MUST NOT depend on deprecated packages and we'd be done. Maybe add a note to check your dependencies to see if they provide "deprecated" in the review checklist. fedora-review could even do it, if it were still maintained.

@tibbs Surely, logically, all guidelines are review guidelines? A package needs to meet the guidelines to pass review and we don't actively revisit packages in dist-git against the guidelines when the guidelines are modified... isn't that semantics or am I missing something?

It's a good point about how to notify deprecation. I think we need to tightly scope to what "deprecated" means in the context of this. Perhaps it's worthwhile to spend a little time discussing how to handle a package that is deemed deprecated, but is not obsoleted in the repos and we still ship whilst it's considered deprecated?

How about ... if intention is to deprecate a package that has dependent packages within the distribution (not this is not the same as orphaning or retiring) an issue should be raised with FESCo with the explanation why requesting approval to mark it deprecated and to carry out the mass bug filing.

On approval by FESCo a tracking bug must be assigned, and all dependent packages identified for mass bug filing have their bugs block this. The package that is being deprecated must have have a Provides: deprecated added to it with a comment referencing the bugzilla ticket for the tracking bug.

This is actually made easier, if it's a group effort to deal with a package deprecation, with the change to pagure as if it's not the actual maintainer (if there effectively is no maintainer) carrying out the deprecation (as in this case with net-tools) then a PR against the spec and a poke to the -devel mailing list for provenpackager help ought to suffice to get the spec updated.

With that process.policy in place it does indeed make the guideline much easier to search for any "officially deprecated" package.

I erred on the side of being more inclusive with packages, hence the SHOULD NOT rather than MUST NOT, but with a mechanism to track our "tech debt" ... but considering the review process covers new incoming packages I can see a valid argument on the direct MUST NOT depend on a package marked deprecated ... and as part of the review then it'd be required to either work with upstream for a new release that removes that dependency or with a maintainer patch to handle the situation (with comment to issue upstream as per usual guidelines).

Err ... I didn't realise fedora-review was no longer maintained ... seeing as we point all packagers to it as the tool to use to assist in reviews and encourage reviewers to copy/paste the report into the review .... isn't this a fairly critical thing to the community to ensure it is maintained?

We discussed this at last weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-11-09/fpc.2017-11-09-17.00.txt):

• x723 Guidelines for handling deprecated dependencies during review
  (geppetto, 17:06:27)

cough I'm frequently on IRC!

Anyway ... this is somewhat hypothetical rather than a specific thing i've encountered in deprecating this package but I feel it's an important thing to get right for our agreed processes as it's a topic I suspect will come up more often as time moves on.

For example the tcp_wrappers on that was just agreed is likely to cause similar pains without guidelines on how to prevent this: https://fedoraproject.org/wiki/Changes/Deprecate_TCP_wrappers

I do agree that a provides: deprecated or similar is sufficient, with the guidelines against that being in a package.

I don't think we have an official process to deprecate a package and we would need one before we can expect package maintainers to start adding Provides: deprecated(%{name}) or something similar to their packages and carrying it for some time before retiring.
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life is not in FPC restricted namespace, so feel free to edit that one. There's also this page: https://fedoraproject.org/wiki/Deprecated_packages , but it's also unofficial.

I don't think we can require maintainers to not depend on deprecated packages if there's no way to know which packages are deprecated.

We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2017-12-13/fpc.2017-12-13-18.00.txt):

• x723 Guidelines for handling deprecated dependencies during review
  (geppetto, 18:16:55)
• We generally agree with adding the provides, at least. Need a draft
  though. (geppetto, 18:24:03)

I don't think we have an official process to deprecate a package and we would need one before we can expect package maintainers to start adding Provides: deprecated(%{name}) or something similar to their packages and carrying it for some time before retiring.
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life is not in FPC restricted namespace, so feel free to edit that one. There's also this page: https://fedoraproject.org/wiki/Deprecated_packages , but it's also unofficial.

I don't think we can require maintainers to not depend on deprecated packages if there's no way to know which packages are deprecated.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2018-04-12/fpc.2018-04-12-16.00.txt):

• x723 Guidelines for handling deprecated dependencies during review
  (geppetto, 16:24:59)
• ACTION: mhroncok Will prep. a draft (geppetto, 16:32:51)

First draft https://fedoraproject.org/wiki/User:Churchyard/Packaging:Deprecating_Packages

@churchyard I would prefer if we could do Provides: deprecated() without having name of packages in there. In that case, it would be much easier to find such packages and we could do some automated checks.

Moreover, we could automate adding those provides to all subpackages by having some macro like _deprecated_package when it is defined, RPM would add those provides automagically. This way we could tune provides as necessary without bothering packagers.

I don't have a problem with that. I just went with what was proposed in this ticket. Having the name in there is IMHO not necessary.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2018-05-24/fpc.2018-05-24-16.00.txt):

• x723 Guidelines for handling deprecated dependencies during review
  (geppetto, 16:28:09)
• LINK:
  https://fedoraproject.org/wiki/User:Churchyard/Packaging:Deprecating_Packages
  (geppetto, 16:28:37)
• Got +4 for no %name (geppetto, 16:57:24)

To expand a bit:

The meeting proceeded with quorum but one member went AFK. Quorum rules on IRC are kind of difficult to formulate; we generally just collect and note the votes we have and leave the matter open. If additional votes are made in the ticket then the draft is accepted. Otherwise it just gets brought up at the next meeting.

Two separate issues relating to the draft were discussed:
Whether %name is needed in the Provides: line.
Whether the restriction on adding a dependency on a deprecated package should be strong ("MUST NOT") as in the presented draft, or weaker ("SHOULD NOT").

I won't try to characterize everyone's opinions on that; they're in the log.

The final vote was +4 for the draft modified to remove %name (with "MUST NOT" left in place), so deprecated packages would just add Provides: deprecated(). That just needs a fifth +1 by any remaining committee member and I'll write it up. But if you do have a preference on any of the above two points, please do say so.

How about:

Provides: deprecated() = 20210101

Instead of TODO: Check again for removal in 2021. Or may be there could be some addition keyword in the brackets, which could give some hint when the package was deprecated and when it will be removed ...

(+1 vote from me, so we can move this forward.)

I also agree that %name isn't necessary.

+1 vote from me a well (for the draft modified to remove %name)

@vondruch that was an example note from the maintainer to himself. not a promise. you make it sound like a promise. I can remove the comment form the draft not to confuse anybody.

@churchyard From my POV, it should be clear how long the functionality will be available until it is removed. This does not mean it will be removed on that date, but it would be queryable and definitely more consistent then some random comment.

Hi all,

Just wanted to give a quick "thank you" to the committee for continuing this discussion and driving forward to reach a policy whilst I've been busy with $life.

@vondruch it's not always easy to determine that sort of date though ...

Take the situation that engaged this discussion for instance. FESCo agreed that it was a laudable goal to fully deprecate net-tools in Fedora and ensure no package in our archive depended on it (without a significant reason) and gave their blessing for my mini-crusade.

I am not the net-tools POC for the package (actually @mruprich has never weighed in to my recollection) but have been willing to carry a torch, file bugs and work with upstreams and update packages over the past year.

Without much in the way of assistance there's no real date I can give for the deprecation to be "complete" and at that time the package itself will still exist in the archive for as long as its maintained for those who still want it for some reason or other ...

We haven't had many situations like this though ... it's rare that a tool gets deprecated but manages to hang on as long as net-tools has.

I don't think it's bad that policy SHOULD have an estimate for how long it will exist ... but it shouldn't be a MUST in that area.

@jhogarth I never weighed in because I just found out today about this when you mentioned me in this conversation.

I would be more than happy to help with any deprecation process in net-tools.

@vondruch it's not always easy to determine that sort of date though ...

1. This might always be optional
2. This will be hardly some hard deadline. This is more as safetynet and warning. People who care will use this to prioritize their work. If they don't make it, the date will be very likely postponed. At the end, it is the same as write the "TODO: Check again for removal in 2021" above. The thing is that you cannot query such comment, while you can easily query the Provides. There is not reason to not use it.

Oh if that's the approach I'd back it yeah ... that makes sense indeed.

@vondruch So we say thta's the date the maintainer will check it again and either remove the tool or postpone the date. We also say it's a SHOULD (or even MAY), not a MUST.

How does that work for others?

@vondruch So we say thta's the date the maintainer will check it again and either remove the tool or postpone the date. We also say it's a SHOULD (or even MAY), not a MUST.

That works for me.

I'm fine with including a date, but note that we should stay well away from making any kind of distro policy regarding how deprecation works, how dates are arrived at, what happens if a date is missed, etc. I assume that any type of deprecation like this would be associated with something which has gone through the FESCo change policy, and thus at best we would link to some policy that FESCo has made.

I think I would be in support of at most something like the following:

If a date for the deprecation is known, it can be included as follows:

Provides: deprecated() = YYYYMMDD

and leave it at that. The rest isn't within our purview.

+1 to that

@tibbs I concur, I don't think we need any other policy. As with other stuff such as .spec cleanups, I expect that from time to time, somebody will probably look at the dates and either query what is the state or take some action.

From: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-05-31/fpc.2018-05-31-16.00.txt

• x723 Guidelines for handling deprecated dependencies during review
  (geppetto, 16:06:21)
• ACTION: Deprecation guideline with no %name but optional date.
  (+1:5, 0:0, -1:0) (geppetto, 16:20:28)

I'll update the proposal and send the text for @tibbs to review.

Ready at https://fedoraproject.org/wiki/User:Churchyard/Packaging:Deprecating_Packages

Recent changes https://fedoraproject.org/w/index.php?title=User%3AChurchyard%2FPackaging%3ADeprecating_Packages&type=revision&diff=520113&oldid=517594

@tibbs may I go ahead and put this to https://fedoraproject.org/wiki/Packaging:Deprecating_Packages and link it from the main page, possibly bellow https://fedoraproject.org/wiki/Packaging:Guidelines#Conflicts ?

Announcement text:

A new guideline page relating to package deprecation has been added, and both the main guidelines and review guidelines have been updated to reference it.

• https://fedoraproject.org/wiki/Packaging:Deprecating_Packages
• https://fedoraproject.org/wiki/Packaging:Guidelines#Deprecating_Packages
• https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Things_To_Check_On_Review
• https://pagure.io/packaging-committee/issue/723