Re: [Dwai-developers] TODOs

[Lucio C. <lu...@su...>]

Lash wrote:
> why the repository's URL is optional?? he objective of dawi isnt add
> the repository URL to source.list file?
More or less. The objective of dwai is to make the installation of a package 
found on a webpage a foolproof task. Adding the correct source in 
sources.list is only one step, important but not strictly required. Suppose 
Ian Murdock wants to put a DEW in place for the package libc6. It's a sure 
bet the required source is already configured in sources.list, and specifying 
an additional source such as ftp.debian.org is only harmful, because the end 
user could point to a different mirror. One could argue that when firefox 
reaches a DEW that means that libc6 is already installed and working on that 
system, however we could have other similar and less impossible examples.

However, while writing the above, I realized that the current DF has a 
limitation: it's not possible to specify a list of equivalent repositories (a 
list of mirrors), and this is quite a big limitation. I'm going to do the 
required modifications to the DF this evening.

> why we take the dependecy?? if we install the package with apt!
Of course, but the installation of the package is only the final step. Before 
installing the package, the DC has to choose the most appropriate one for the 
client system (because each .dwai file can carry more than one version of 
each package). In common circumstances, one of the packages referenced in 
the .dwai file will be designed for the debian flavor of the client system; 
however if the user is out of luck, his debian flavor (say kubuntu 5.10) 
won't be listed in the .dwai file. This doesn't mean that there isn't a 
version of that package which is installable on a kubuntu 5.10 system, but 
only that the dewmaster doesn't know which version of the package fits better 
in a kubuntu 5.10 system. In this case is up to the DC to choose the most 
appropriate one. The most appropriate package is the most recent between the 
ones whose dependencies can be satisfied by the kubuntu 5.10 system. So the 
DC needs to know the dependencies list before even modifying the 
sources.list, let alone downloading the package.

> dpkg -I packagename | grep Depends | cut -d : -f 2
> or
> dpkg -I packagename | grep Depends | cut -d : -f 2 | cut -d \  -f 1
> for the first depend package
Is the output of dpkg -l standard enough to rely on that? Don't we run the 
risk to have different outputs for different versions of apt?

> > What about Python?
> It's ok
> > What about Java
> No! please
When I wrote the world "Java" I was already suspecting that someone would have 
replied this way. Java is there just in case we don't find anything else and, 
since I know Java, it would be easy for me to use that (it has all the 
necessary XML stuff straight builtin). However I know C++ also and I'd be 
happy to learn Python.

> > C++?
> It's my favourite!
What about XML? Do you know which libraries are needed for it?

>> 1 - Reading the ar format directly (not that wise in my opinion
>> unless we know the .deb ar format won't change frequently)
>we can do an explode with the : char
I don't know what the : char does, however I guess it extracts the ar 
contents. The problem is: how standard are those contents? Can we rely on 
them (in particular the dep list) being always the same between apt versions?