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

Re: blends-dev, gsoc 2013

Hello Andreas,

On Tue, Jun 18, 2013 at 12:20 PM, Andreas Tille <andreas@an3as.eu> wrote:

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?

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). 

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

  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.

If you think the data from this sql statement is  sufficient, I will start writing the new blends_gen_control. 
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.

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


in the script


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.

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: