firehose-devel September 2013

firehose-devel@lists.fedoraproject.org

4 participants
2 discussions

Q: handling of multiple <analysis> elements.
by Alec Leamas 11 Sep '13

11 Sep '13

So, I'm backl... While working with the fedora stuff there is a need to transform analysis elements using xslt. While it's perfectly doable on a single element, it does not scale very well. The natural solution is to apply the xsl file to a stream af analyse elements. For this to work (xslt requires well-formed input) the analysis elements must be wrapped in a root container element. Now, this is not hard, I've been using <analyses-container>. My question is just if there is a general need to standardize not only <analysis> but also container element holding some of these? And yes, I'm not that fluent in xml... --alec

1 0

Revisited: fedora-review
by Alec Leamas 10 Sep '13

10 Sep '13

After digesting your remarks I have updated the xml produced by fedora-review: - Adding source file info, but without sourceline/function etc. This should make it possible for a UI to just display the spec file, which is the proper action here. - Adding a custom field for type of warning, similar to the error/warning distinction used by many checkers. New example: http://ur1.ca/f9dua Questions: - Is the general idea here that the if the UI just knows the name of the source rpm, it knows how to retrieve and unpack it, giving access to the sources? Or? (BTW, how does this apply to debian?). In other words, I kind of miss an overall usage scenario description. - In particular, what's the point of the individual file hash if you know the state of the source rpm? - Are there any UI attempts (even just some simple scripts) which is running in a Fedora context I can test things on? The debian stuff (firewoes) looks nice... As does the idea of adding a firehose xml output option to rpmlint. Cheers! --alec

4 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

firehose-devel September 2013