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

Re: getData and a new upload of autodocksuite




----- Mail original -----
> De: "Steffen Möller" <steffen_moeller@gmx.de>
> À: debian-med@lists.debian.org
> Envoyé: Lundi 5 Septembre 2011 11:09:18
> Objet: Re: getData and a new upload of autodocksuite
> Hi Olivier,
> 
> On 09/05/2011 07:59 AM, Olivier Sallou wrote:
> > [...]
> >> My basic question to you guys now would be
> >> 0) do you share the vision that the packages should come with
> >> instructions how to get the data, not the getData package itself?
> > This is a difficult point. Data location/format may change in time,
> > and impacts the software package in this case (let's http location
> > change), and all packages needing it.... But, post download
> > processes is specific to each package so....
> This basically means there is no ultimate answer but it all depends on
> the respective data and if upstream happens to be moving or whatever.
> 
> It would all be less of a concern as long as we are only using testing
> or unstable. What worries me is the transition of outdated
> instructions
> to stable - and we are with a few exceptions not using backports.d.o.,
> yet.
> 
> We could think about maintaining such download instructions online.
> >> a) how can we have something that both BioMaj (because it is nice)
> >> and
> >> getData (because it is easy for me at least) can work with
> > Biomaj takes in charge the download etc... so setting direct
> > commands will not work directly.
> > However, biomaj could parse this kind of data. The impact is data
> > package will not use all biomaj features.
> > One nice point however would be to set the source without the wget
> > etc..., only the URL (or to separate those in "source" and
> > "download" for example)
> > Biomaj use mainly URLs and regexp to know what need to be
> > downloaded, however a description need to be generic e.g. tool
> > agnostic (to be able to use any tool and ease tools changes).
> I am very much with you. getData once set out to do just that.
> 
> My hunch was that with something close to Perl (or any other scripting
> language) we would not be limited to any official commands for the
> post
> installation. And everyone would immediately see what the instructions
> mean.

I agree regarding post processes, but if you want to call getData or other with a bank descriptor you need to specify the tool.
At some time you will call 'getData { source: '' , post: ' find . chmod etc..' ...} (or whatever the format)
What I suggest is calling something like "datamngr -f bank.desc" with bank.desc containing the above.
datamngr would be an "alternative" program pointing to getData,Biomaj or other.
datamngr programs would just need to understand a bank descriptor (and then you are tool agnostic).

> 
> > Regarding Biomaj/Getdata/other, what would be required I think is a
> > generic tool name and to use system alternatives. User would set in
> > Depends either the generic name (for any) or a specific tool name.
> > In postinst he would exec the data download/update task with the
> > generic tool name.
> I need to see it to understand it :)
> >> b) how shall we define the permissions for getData of the data
> >> directory?
> > Well, a specific data directory must be used for all "data"
> > (/var/lib/med/data?, or whatever...).
> It defaults to /var/lib/getdata for the moment and can be specified at
> runtime.
> > It should be read-only for other users. This directory should be
> > used for data access but should not be modified, I think, by the
> > user.
> Are you creating a user for biomaj to own the data, like dataadm? It
> seems like getData should then use the same, if you don't mind.
> 

I don't create any specific user. This is not required by application I think (no security matter here).


> Many greetings
> 
> Steffen
> 
> 
> --
> To UNSUBSCRIBE, email to debian-med-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive: [🔎] 4E6491BE.9030505@gmx.de">http://lists.debian.org/[🔎] 4E6491BE.9030505@gmx.de


Reply to: