Re: blends-dev, gsoc 2013
Hi Emmanouil,
On Mon, Jun 17, 2013 at 06:05:21PM +0300, Emmanouil Kiagias wrote:
>
> 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
Hmmm, somehow the commit hook does not seem to work. The web archive[1]
does not show the change. Could you please have a look into this?
> Now it contains the distribution, the component and I also included the
> packages with architecture "all" (I think it covers the info you
> mentioned).
Yes. From this matrix you can decide whether to put a package into
Depends or Suggests. You could even add a status field for checking
like
CASE WHEN distribution = 'debian' AND
dependency = 'd' AND
component = 'main'
THEN 'Depends' ELSE 'Suggests END AS status
(or whatever name you want to give this column).
This should work also for architectures where the package does not exist for
instance if you try
./blendsd debian-med testing armel
the component is empty (and thus != 'main') which should be sufficient
to create the architecture dependant control files.
BTW, I'd recommend adding some "ORDER BY package, task" in the end to
enable reproducible results which are helpful for debugging.
> In case a package is from other distribution than debian (eg
> ubuntu, new etc) do we need other info than that?
No. Not if we are building the metapackages for Debian.
> 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?
Just "suggests" as you say.
> > 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).
I'm fine with any way you choose. If you are brave enough I do not have
any problem if you takle the diff approach first. However, when thinking
twice about this we could make use of those JSON files also for other
purposes. If you look into
git://git.debian.org/git/blends/website.git
in the script
website/misc/team_analysis_tools/count-dependencies.py
which you call like
count-dependencies.py <path_to_svn_checkout_of svn://svn.debian.org/svn/blends>
you see some vague attempt to create some package statistics. I'm a bit
worried that I need to rewrite this for Git which is probably easy but
maintaining it for SVN *and* Git (for some period) would be a bit
cumbersome. Having a simple to parse JSON database in every tag might
help here (and perhaps for other interesting statistics). So dumping
the status into some JSON file and deliver it with the source might have
additional advantages.
Kind regards
Andreas.
[1] http://lists.alioth.debian.org/pipermail/blends-commit/2013-June/thread.html
--
http://fam-tille.de
Reply to: