Re: [GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)

[Andreas Tille <andreas@an3as.eu>]

Hi Emmanouil,

On Fri, Jun 21, 2013 at 07:29:51PM +0300, Emmanouil Kiagias wrote:
> > UDD is configured to give guest read access - so why not simplify your
> > code?  To give you an example that works for all machines I'm working
> > on you can have a look into
> >
> Thanks I will do it that way.

Fine.

> > AttributeError: 'NoneType' object has no attribute 'execute'
> >
> > Hmmm, no time to check what went wrong here, may be you could catch this
> > exception and provide a better error message.
> >
> That mean that the cursor has not initialized (has stayed None) , my bad I
> forgot to define cur as *global*, in my computer was working. Anyway I will
> avoid using *globals* in my code, I will change the existing code so we
> will avoid such problems.

OK.

> > In general I'd prefer some defaults that will enable me to get reasonable
> > results even when leaving out the arguments:
> >
> >   --blend:   This becomes redundant once you call blend-gen-control in a
> >              directory that contains the source of a certain Blend
> >
> Yes I know that but for the moment I keep this argument cause it's easier
> for testing the script.

Ok.  Makes sense.

> >   --release: As discussed previously we should target at the available
> >              packages in testing.  The option is nice to have but I would
> >              recommend setting "testing" as default
> >
> Ok I will make the --release argument optional and the default value will
> be "testing".

+1

> >   --architecture: This is more complex.  Finally we want to build *one*
> >              source package that fits *all* architectures.  For the moment
> >              we could go with the manual specification (or setting the
> >              currrent architecture as default).
> 
> Ok, so for the moment I will go with the manual (or if no argument is
> passed I will the current architecture)

OK.

> >              However, finally you will
> >              need to dig the archives / ask on mailing lists what syntax to
> >              use to get a source package that will create the right
> >              dependencies according to the architecture the source package
> >              was build on.  There are such packages inside the Debian
> >              archive but I admit I never dealt with this before and also
> >              would need to do some research first
> 
> No problem, I would love to make some research :-). As soon as we have a
> simple working blend-gen-control we can then customize it and bring it to
> the actual production needs.

Yep.

> >              So what we create is a source package containing either one
> >              control file or several of them (one for each architecture)
> >              and once the binary packages are built from this source the
> >              correct architecture needs to come into effect to get the
> >              correct dependencies for this architecture.
> >
> If you also agree I can keep it simple for the moment and make a
> blend-gen-control to generate *one* control file(like the existing
> blends-dev) for a provided architecture, and once we have that we can
> organize how it will create the final source package?

It is perfectly fine to keep it simple in the beginning.  I just mentioned
it in connection with the options that needed to be given to the script.

Kind regards

    Andreas.

-- 
http://fam-tille.de