[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: blends-dev, gsoc 2013

Hi Emmanouil,

On Tue, Jun 18, 2013 at 10:58:11PM +0300, Emmanouil Kiagias wrote:
> I changed the /git/blends/blends-gsoc/config and added "hooks" section, I
> just made a new commit. I will check if it works now(if not I will check it
> again).

Hmm, nothing in my inbox...

> >   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.
> >
> I added a new sql script blendsd_fix (replica of blendsd) which uses CASE
> to fix the dependency column as we have described.

Hmmm, it certainly does what it should do but I might like to stress
that this is actually no *fix*.  The original column "dependency" just
stores what is given inside the tasks file.  The calculated value we
need for the control file is just something else.  So overriding the
original value of depends is not a good idea if we want to use the
output for verifying the correctness of our query because it hides the
dependency given inside the tasks file.

> If you think the data from this sql statement is  sufficient, I will start
> writing the new blends_gen_control.

Yes, IMHO you can start with this. 

> > BTW, I'd recommend adding some "ORDER BY package, task" in the end to
> > enable reproducible results which are helpful for debugging.
> Yeap that would be helpful, I just forgot to commit this change, I can
> updated it in the next commit.
... to verify the commit hook? ;-)

> > 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.
> >
> >
> Ok, as soon as we finish the blend-gen-control I will test both
> ways(although in that case the JSON approach seems better and easier), in
> any case the implemented way will be useful for creating  package
> statistics (it is interesting :-) )


Kind regards



Reply to: