Hello Andreas,
On Mon, Jun 17, 2013 at 2:22 PM, Andreas Tille <[email protected]> wrote: > > > git://git.debian.org/git/blends/blends-gsoc.git > > So if anybody wants to test it it might make sense to check it out from > there. I noticed that the result does not enable one from > distinguishing the status of the packages properly. You only check for > specific architecture or not. But we do also have > > autodocktools -> non-free (and thus should be rendered as > Suggests) > wgs-assembler -> not in Debian (also rendered as Suggests) > > Moreover you have no real distinction between the fact whether a package > is simply "Architecture: all" or whether it is simply not available for > this architecture. For instance if you look at soapdenovo[1] it is not > available for several architectures - but in your result set this is not > reflected. > Yes you are right, I missed those information from the query, I updated the sql/blendsd you can check it out: git://git.debian.org/git/blends/blends-gsoc.git Now it contains the distribution, the component and I also included the packages with architecture "all" (I think it covers the info you mentioned). In case a package is from other distribution than debian (eg ubuntu, new etc) do we need other info than that? I mean do we need to know if the package exists in (eg) ubuntu if it also exists for the selected architecture etc, or we will just add it to "suggested" no matter the other info? As I said we could use VCS but I'm not fully convinced that relying on > diff to get structured information. While we can test it fir sure > whether it works out practical as an alternative approach I would > consider just dumping the status of a release as JSON data right into > the source package. While we will not be able to create changelogs to > previous releases I would consider this a minor flaw because those > changelogs are just written (as bad as they are, thought). We will not > change those changelogs afterwards anyway. So if we create some file, > say <blend-name>.json with every run we could (also relying on VCS tags) > just compare the fresh data with the JSON data from last release. IMHO > this comes more handy than a diff which needs to be parsed carefully > which might come more expensive that just browsing a JSON file. > Ok I can do it first the json way and then I could test out the svn/git as an alternative way(to see if it works and if its practical). > Right. I would delay this a bit. > > Yes i also agree. Kind regards Emmanouil
