Re: [GSoC] Prospective packages importer
On Sat, Aug 22, 2015 at 10:25:44PM +0530, Akshita Jha wrote:
> > Well, I think both possibilities (use one table for all or two tables)
> > are technically equal from an SQL point of view. From an UDD point of
> > view it works usually in a way "truncate the table include data from
> > scratch". In this aspect a separate table would fit the philosophy a
> > bit more *if* (and only if) you decide for a separate script for the
> > import. If you just want to enhance the existing prospective package
> > importer I fully agree with you.
>
> Hmm. Ok. So, a separate script seems like a better idea for now. The new
> table can be "blends_unknown_packages". Is the name alright ?
Yes, this does sound sensible.
> > The fields with X- are basically comments for the task file editor so
> > you can ignore this one. Do we have "Note" fields? Without checking
> > the docs I think this is undocumented and should be turned to either
> > "Remark" or X-Note (=be ignored).
> >
> Ok. I'll not add X-category, X-importance. The Note fields is present.
>
> eg 1)
>
> Depends: amoscmp
> Homepage: http://amos.sourceforge.net/docs/pipeline/AMOScmp.html
> License: Artistic
> Pkg-Description: comparative genome assembly package
> .
> .
> .
> modular open-source framework for assembly development.
> Note: Genome assembly and large-scale genome alignment (
> http://www.cbcb.umd.edu/software/)
That's gone now.
> eg 2)
>
> Depends: splitstree
> Homepage:
> http://www-ab.informatik.uni-tuebingen.de/software/splitstree3/welcome.html
> License: to be clarified
> .
> .
> .
> Note: There is a new version 4.0 written from scratch at
> http://www.splitstree.org/ which requires a license key - so this is
> probably non-free. Version 3.2 which is linked above has some
> downloadable source code without any license or copyright statement -
> so it has to be clarified whether we are able to distribute this code
> or not.
> Remark: This package ships with BioLinux
> http://envgen.nox.ac.uk/biolinux.html
That's cheating. ;-)
It does not fit '^Note:' but rather '^ Note:' (mind the space in the
beginning which makes this part of the free text description.
> There is a note and also a remark.
Not really since the Note is part of Description in this case.
> The Note is not displayed in the current tasks files. It is probably
> treated as X-note. So, should I ignore this ?
Yes, ignore (even if the reason to ignore is differen ;-))
> > Fine.
>
> Since, I plan on using a separate table for inserting these prospective
> packages, we don't need to alter the current blends_prospectivepackages
> table. It seems information like - enhances, language etc. do not need to
> be added for the existing prospective packages. We may not need to add
> extra columns to the table.
Yes.
> > BTW, an idea came into my mind that we have even Remarks for *existing*
> > packages. These would get lost if we only have remarks for the
> > prospective packages. So we need an extra table
> >
> > package | remark
> >
> > Does this sound sensible to you?
>
> Yes. It is a really good idea. A separate table say "package_remarks" will
> cover the remarks for all packages (not just prospective ones).
Yes, that's the idea.
> > > Do you think all this information will be made available for
> > > all packages in the long run ?
> >
> > I do not understand this question.
>
> What I meant was, most of the columns will be empty for now. Say, most
> packages do not have information (like 'language') now. Will the 'language'
> for all packages in the table be made available some time in future ? I
> hope I am clear in my question now.
The existing Debian packages do not have this information. I have no
idea whether this will be maintained in the tasks files. I admit it is
an unimportant piece of information - so it would be even safe to drop
this field at all.
> > Create a separate sql script and I'll merge.
> >
>
> So, the sql script will include:
>
> Creating two new tables - blends_unknown_packages and package_remarks.
Yes.
> Is there anything else I am missing out ?
I think that's complete.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: