#189 Filtering Guidelines outdated
Closed: Fixed None Opened 11 years ago by leamas.

The filtering guidelines at [http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering] is outdated. They recommend mechanisms that shouldn't really be used, and has limitations on what packages which can be filtered causing packagers to make all sorts of walk-arounds (I actually considered creating two packages from same source...)

See thread on fedora-devel: [http://lists.fedoraproject.org/pipermail/devel/2012-June/169174.html]

I suggest that the Filtering section is updated. Until this is done, please insert a warning about current state.


We can't get this rolling until someone who knows how the new filtering works submits a draft.

Simple patch to remove limitations on what can be filtered
filtering.patch

This is now almost half a year old. I suggest applying the attached patch which removes a very confusing part which is plain wrong; this is obvious looking at the email thread. This will not make the guidelines up to date, certainly not, but will remove the single most outdated part IMHO.

Started on a draft: https://fedoraproject.org/wiki/User:Toshio/AutoProvidesAndRequiresFilteringDraft

Unfortunately, there's somethings that need to be finished.

  • Have panu or the rpm-team review the draft to make sure it's accurate (in particular, I removed the rpm coloring warning because I think this method of doing things won't interfere with that but we need to check).
  • Someone needs to change the perl_default_filter to use these macros instead -- or leave it out of the new guidelines. Otherwise, the perl_default_filter would affect rpm coloring whereas none of the rest of the guidelines would.

Some notes in the Discussion tab for Toshio's draft

I've moved the request out to the proper place in the draft (Talk pages are failure for a drafting process... they're really only applicable to the wikipedia workflow where a document needs to be polished for the viewer at all times and so the discussion about it needs to happen at another place).

Reading the discussion, I think that at present the guidelines could point to the caveats to filtering a private library but can't really make a recommendation for implementing that's easy to use:

Use __provides_exclude and __requires_exclude with the same list because the automatic dependency generator is going to find the same symbols in provides and requires. Generating the list is an exercise for the packager.

Someone could probably write something that generates the list of provides that the files matched by a regular expression would have created and then exclude those from both provides and requires. However, that's out of scope for the guidelines... we'd point to it once written but not write the code to implement it into the guidelines page.

Agreed. Since it's not possible to write a GL which is easy to use one has to write one which is hard to use (sigh). Still much better than no advice at all, though. In particular, I agree that the (current) solutions to generate the list of libs to exclude are to complicated to be in the GL.

After all, this should really be a RPM bug ticket IMHO.

Okay, new version of the Draft: https://fedoraproject.org/wiki/User:Toshio/AutoProvidesAndRequiresFilteringDraft

I'll ping panu to see if he can give it a quick look for obvious errors.

Just a note that I just found tibbs's earlier work in this ticket: https://fedorahosted.org/fpc/ticket/76

I'm going through and trying to figure out what things should be added/changed in the draft (mention of the regex standard being used, more detailed instructions on adding to perl_default_filter, and more information about escaping look like things we should incorporate.)

Draft updated and email sent to panu.

In his reply, Panu mentions that the perl macros and the method of overriding them look "fishy". I think he's saying that they're a bit complex and it's hard to evaluate how the rpm spec file parser and the regular expression engine are going to interact with the attempt to expand and then add to the previously defined macros. He recommends we test that if we leave it in.

He also pointed at this email showing that the ternary expression in the perl macros are being mis-typed a lot, leading to errors that the packagers aren't currently seeing:

http://lists.rpm.org/pipermail/rpm-list/2013-January/001359.html

I've updated the perl strategy for overriding the default macro due to Panu's comments. Instead of using iarnell's ternary expression to expand the current macro I've switched to a copy and paste strategy with an explanation of why. https://fedoraproject.org/wiki/User:Toshio/AutoProvidesAndRequiresFilteringDraft#Perl

Current vote on filtering update is (+1: 4, 0:0, -1:0) will continue vote in ticket.

Lacking votes from: tibbs (favorable in meeting but needed to leave before we voted), spot, Rathann, racor, rdieter

+1 for this from me.

We've reached +5 so this passes. I'll write it up in the Guidelines.

Guidelines written up.

Announcement text:

https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering

The autoprovides and requires filtering guidelines have (finally!) been updated to take advantage of features in rpm-4.9.x. Packagers making use of filtering, for instance compiled extensions to scripting languages from being provided as though they were a shared library, should take a look at the guidelines and update their spec files accordingly. This includes packages which are overriding the %perl_default_filter macro as the previous ways of overriding that macro have lead to quite a few silent bugs http://lists.rpm.org/pipermail/rpm-list/2013-January/001359.html .

The new guidelines work on all Fedora versions but EPEL6 and below will need to follow different formulas: https://fedoraproject.org/wiki/EPEL:Packaging#Provides_and_Requires_Filtering

The previous method of filtering autoprovides and requires will continue to limp along but it has many known caveats so packagers are encouraged to update their packages at their earliest convenience.

Wow, this one has been sitting for ages. There's announcement text but I don't know if this stuff is still relevant.

I think I'm just going to pretend we announced this ages ago.

And it turns out I announced it anyway. Oh, well, at least we're mostly caught up now.

Metadata Update from @leamas:
- Issue assigned to spot

7 years ago

Login to comment on this ticket.

Metadata