Hi, On Tue, Oct 04, 2016 at 12:23:00AM +0200, Andreas Pretzsch wrote: > On Mi, 2015-02-11 at 12:19 +0100, Juergen Borleis wrote: > > On Wednesday 11 February 2015 11:50:16 Hubert Feurstein wrote: > > > IMHO the proposal by Markus makes sense. I have had the same issues > > > with collecting license texts in the past. So a solution integrated in > > > PTXdist would be great. Because then it would be possible to collect > > > the license texts depending on the config options of a package > > > (sometimes plugins have a different license). > > > > Please checkout current PTXdist master and run "ptxdist make > > license-report" > > inside a PTXdist project. You need "LATEX" and "dot" to make it work. > > First, this one is wonderful, and works like a charm. Thanks a lot. > > What I am missing is an overview. > Mainly as an external list, but maybe also in the reports. > > I'm talking about e.g. a simple CSV, listing all the included packages, > like in "pkgname | pkgversion | licenses". So something like > [...] > busybox|1.24.2|GPL-2.0 > [...] > Sensible escaping would be something to look at, but anyway. > > Point is, this list would be easily diff'able between releases. > And lawyers tend to be more expensive than developers... > > Also, one can sort it and make matrices of any kind, e.g. sort by GPLv3, > and so on. > > Above would be the minimum information, for anything else, one can look > into the big report. Maybe the flags like "attribution" and "choice" > would be interessting, too. > > Now, this can be done with some shell scripting, outside of the build > process. > But as there is already the license-report generation, this would be the > perfect place for it. > > Has anyone already (partly) implemented this ? > Would be happy to pick up the pieces and also mainline it. Just asking, > before I start hacking things twice...
I don't think there are any implementations like this. If we do something like this, then I'd like to take this a step further. I think there are more use-cases for data like this. And there a probably conflicting requirements for the different files and output formats. The main issue with PTXdist is that we cannot just iterate over all packages is one script. So what I'd like to see is something like the current report stage to aggregate all possibly interesting data about the packages and later convert an filter that into the required output. What would be a good intermediate format for this? I'd like to avoid escaping problems if possible. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ ptxdist mailing list ptxdist@pengutronix.de
