On Wed, 28 Sep 2011 21:49, Robert Schweikert <rjschwei@...> wrote:

Hi,

As agreed at osc11 I am working to add version numbers to the library whitelist such that we can gradually eliminate the list and enforce the library policy on all appropriate packages.

While processing the list I have found a number of packages listed that no longer exist, such as libEMF1 or libglibsharpglue-2. IMHO we should just remove these from the list. There should be no harm, unless there are false positives, i.e. packages I was not able to find but they exist. One such example may be libXrender. libXrender is listed in the whitelist as libXrender1 and it cannot be found using "osc bse". However, using the web search interface one can find xorg-x11-libXrender. This leads me to my next question. How is the whitelist used? Exact matches or loose matches, i.e. the libXrender1 listing matches xorg-x11-libXrender and thus exempts it from the policy or, libXrender1 does not match xorg-x11-libXrender and therefore there is no exemption.

Next are the entries in the list that list packages in home: projects. IMHO these should also be removed from the list. Of course we can discuss whether or not packaging policies should be enforced in home projects, but I'd rather not go down that rat hole.

Finally some statistics: Current total entries in the whitelist: 119 Packages only in home: projects: 14 Packages not found: 63

Thus the list would only have 42 entries if we decide to remove everything that cannot be found based on the listed name and things that are in home: projects.

Thought/Comments?

The case of "libXrender" shows clearly: Something is rotten on the state of SUSE. Can those that know more about the whitelisting process please point out / publish the matching rules ? On what to do about, the most rash version: - the found 42 entries in not home projects: check if really needed, if yes, put them on a renewed list with a checked-at-date. - the found 14 entries in home projects: if the library policy IS enforced in home: contact the owner, else drop them. - the rest: crash-test! (put in comments, wait for the next recompile.) Yes ugly. But! Definitely needed. No library package that is not in build service should be on the whitelist. For every entry in the whitelist there should be a explanation why the library policy can not be enforced for this entry and a date / version - stamp of the last check. The situation, as it is now is chaos. - Who put a entry into the whitelist. - When, why, and at which version it was put on the list. - Is the whitelist on a version-control with a ability like 'git blame'? Would reduce the headaches. - How can a build service user check the whitelist? osc ask library-whitelist '<regexp>' for ex. would be nice. Cheers Yamaban. PS: Please, this is food for thought, not distributing blame. And thanks Robert for your work. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Robert Schweikert wrote:

[...] Next are the entries in the list that list packages in home: projects. IMHO these should also be removed from the list. Of course we can discuss whether or not packaging policies should be enforced in home projects, but I'd rather not go down that rat hole.

The policy is applied to home projects as well since rpmlint{,-mini,-Factory} is inherited from the repos one builds against. The rpmlint configuration in Factory is not supposed care about packages outside of Factory though. The whitelist entries that seem to refer to home projects are just referring to former Factory package names. So those entries can be removed. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org