dwai-developers Mailing List for Debian Web AutoInstaller
Status: Beta
Brought to you by:
lucrus
Menu
▾
▴
dwai-developers — Place for developers, be they coders or not
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
(27) |
Apr
(2) |
May
(3) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(7) |
Oct
(2) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lucio C. <lu...@su...> - 2007-06-17 15:56:57
|
Dwai-client version 0.3.2 has been debianized! This is the first step to have it included in Debian, Ubuntu and maybe others one day. The unofficial deb package is available at the SF download area. You can download it, install it with "dpkg -i dwaiclient_0.3.2-1_all.deb" and try it out heading you browser to http://dwai.sourceforge.net/dewpages/index.html The first time your browser will encounter a dwai file it will ask you what to do with it (shared-mime-info integration seems to need a bit of work): choose to open it with /usr/bin/X11/xdwai-client.sh and enjoy! This is one of those little things I'm proud of. Lucio. -- Virtual Bit di Lucio Crusca via Isonzo, 5 10069 - Villar Perosa (TO) http://virtualbit.sulweb.org |
|
From: Lucio C. <lu...@su...> - 2007-04-08 21:08:19
|
So you thought DWAI had died? Wrong. It was just sleeping.
News:
* I've uploaded the latest sources onto SVN at sourceforge
This means that you can now track the development through SVN. If someone is
interested in write access to the repository, please let me know.
* command line syntax of dewmaster has changed
The last stable version of dewmaster (0.2.2) undestands only a single
parameter on the command line: the path to the deb file to use to make the
corresponding .dwai file. The current SVN code does not understand that
single path anymore but understands three options instead:
-d path/to/debs
You can specify a singe deb or a bunch, like '/srv/*.deb' (use single
quotes or otherwise escape the * from bash). If '/srv/' contained any
subdirectories, they are recursively examined.
-u url/to/debs
You can specify a "wget valid" url to download deb files directly and
have dewmaster build the correspondig dwai files. Still alpha, it does
NOT work with wildcards through http (man wget tells us why).
-f config
You can specify a custom config file besides the default ones
(/etc/dwairc and ~/.dwairc). The default ones will be processed anyway
but any variable defined in the custom one will take precedence. This
is a powerful feature for cron based dewmaster calls that have to work
on different repositories.
* dewmaster can now handle several deb files in a single call
Look at the -d and -u options above: there's no more need to use dewmaster for
each deb, you can call it once for them all.
Next steps:
* Make globbing work for both ftp and http (now it works for ftp only).
* Add support for HTML templates in order to automatically create an HTML page
that links to the dwai file for each deb in input (so that you have your
website updated with a single run of dewmaster). The HTML page will include
the link to the dwai file and the description of the package taken directly
from the DEB file itself. Being a template it will fit perfectly in the
website of your choice, because it will be enough to create a template that
matches the site look and feel.
That'all folks!
--
Virtual Bit di Lucio Crusca
via Isonzo, 5
10069 - Villar Perosa (TO)
Italy
VAT No. IT09534960019
http://virtualbit.sulweb.org
|
|
From: Lucio C. <lu...@su...> - 2006-10-18 21:53:35
|
Hello everybody, a new version of dwai-client is available. Changelog: * Documentation fix in README (update-mime-database) * Addded install.sh script, so we now have a script that takes care of installation details, which means that reading the README becomes optional... * Smarter xdwai-client.sh (checks for gnome-terminal, konsole and xterm instead of assuming xterm alone) I've released this version before the italian Linux Day because there really was a need for the install script. Cheers, Lucio. |
|
From: Lucio C. <lu...@su...> - 2006-10-10 21:13:24
|
Hello list, I'm here to announce the availability of a new version of dwai-client. New features in version 0.3.0: 1) XML parsing library has undergone a major rewrite 2) it is now implemented as a state machine 3) the state machine is documented in the doc/ directory (you need OpenOffice.org to read it) 4) it is way faster than previous one. I've run dwai-client 0.3.0 and dwai-client 0.2.0 against the same dwai file. The old version took 48 seconds to parse it, the new version took only 30 seconds, which is a 60% gain in speed, measured in parsed bytes per second. 5) A "broken pipe" bug during XML parsing has hopefully been fixed. The bug showed up in some situations with 0.2.0 and it wasn't reproducible. The old XML parsing code was a mess to debug. The new code is likely to have other bugs but not that one, because it doesn't make heavy use of pipes like the old one. I expect a longer delay before the next dwai release, because I consider the current packages quite stable and useable in order to show them on October 28th, during the italian Linux Day. If you'd like to see the first public presentation of dwai, head Pinerolo (TO) on next Oct. 28! Details at http://pinerolo.linux.it . You might have noticed that we now have four dwai files to try in the demo area of the dwai website. Have fun! Cheers, Lucio. |
|
From: Lucio C. <lu...@su...> - 2006-09-24 16:16:57
|
Hello list, dewmaster 0.2.1 is out. It's only a bugfix release (0.2.0 created output dwai files with incorrect names, see bug report #1564574). The website now has a few dwai files available for tests in the demo section. Feel free to try them. Cheers, Lucio. |
|
From: Lucio C. <lu...@su...> - 2006-09-21 23:12:57
|
Hello friends, dewmaster 0.2.0 is available for download. Changes from 0.1.2 - it includes a php script (get-dwai.php) to set the correct mime type in the http response (because the browser uses shared-mime-info only with the file:// protocol, that is the condition under which I tested dwai-client.sh last time I wrote. As we move to http:// protocol, even on localhost, the browser ignores shared-mime-info and looks only at http headers). - the README includes instruction about the script above With these things in place, it has been possible to publish the FIRST dwai FILE EVER !!! It can be used to install MythTV on Etch. Steps to try it: 1. Install dwai-client.sh on your system, following the README instructions 2. Head your browser to http://dwai.sf.net 3. Go to the demo page, and click "Install MythTV for Debian Etch". 4. Follow the wizard (Yes, Yes... root password, Yes, Yes....OK) 5. Enjoy MythTV!!! If you use Sid, you could try the Etch package anyway, it should work. I'm going to populate the demo page with more dwai files during the following days, but not tonight... Cheers, Lucio. |
|
From: Lucio C. <lu...@su...> - 2006-09-15 23:31:06
|
Hello friends, exciting news tonight! dwai-client-0.2.0 is available for download. New features: * shared-mime-info integration!!! * xterm script * tested with Firefox 1.5!!! The included README tells you how to do everything. No, I'm not drunk, finally we have it! I have clicked on a dwai file (hosted on localhost by now, but that makes no difference) and Firefox asked me what to use to open a "Web autoinstaller file"; then I chose /usr/bin/X11/xdwai-client.sh and a xterm popped up with dwai-client running inside. IT WORKED LIKE A CHARM!!! I'm not sure I can manage to tell you how excited I am. My next step will be to put a bunch of working dwai files online, pointing to real unofficial debs around the world. Dances are opening, we need crew. Goodnight, Lucio. |
|
From: Lucio C. <lu...@su...> - 2006-09-13 22:02:22
|
Hello friends, a new release of dwai-client.sh is available. It addresses some serious bugs in the previous version, while adding a few things. * The previous release had to be run by root, the current release asks for the root password before trying to change system files * NEW: it prompts the user before adding each line in /etc/apt/sources.list * NEW: it shows the user the source line being added * NEW: there is a README * NEW: beta-quality (only minor bugs known in respect to what it is expected to do) I've been in touch with Davide. He's trying to find the time to build a deb package for dwai-client. Meanwhile we realized that it is already too late for inclusion in Etch, unless someone sees the RFP I've reported against wnpp... We still lack a decent website, a few dwai files to throw in it and a script to integrate dwai-client.sh with shared-mime-info. What unofficial deb you'd like to see "dwai-nized" first? wine? something from debian-multimedia? anything else? Cheers, Lucio. |
|
From: Lucio C. <lu...@su...> - 2006-09-04 22:22:17
|
Hello friends, while I wait for your feedback on the dewmaster script and the dwai-client script, I give a draft of the roadmap for the dwai project. Comments are welcome. 1. Integration with shared-mime-info Here we need a tool that the user can launch at will that register the dwai mime type with the mime database and associates it with the dwai-client script. I guess this can be done using something in the package shared-mime-info, but I don't have that package installed just now and I cannot install it for a number of reasons (at least for a few days). If someone has it installed or can install it and takes a look at how to accomplish the work above he/she will deserve my special thanks. 2. Packaging of dwai-client for Debian We need to deb-package the dwai-client script. In other words we need to build dwaiclient-0.1alpha.deb . I hope Davide has time to waste for that, otherwise I'll have to learn how to build a deb package myself. While learning is not a problem, I'd like to have the package included in the stable release of Etch, and there isn't much time anymore. Maybe someone else here knows how to do a deb package. The deb package should use the tool described in #1 in the pre-configure script, so that the dwai-client, as a standard installation step, integrates smoothly with any browser that uses shared-mime-info. I plan to have this deb package within the 20th of september, hoping that it will not be too late for inclusion in Etch. Said that, I badly need a package mantainer within a few days, be it me or anyone else. 3. Building a sample DEW with a few packages We need a DEW (Dwai Enabled Website) to play with. The project website is a good place for it, and we can add a few pages with the .dwai files. We can build .dwai files that point to any deb package on the web. Once we have those 3 things done, we can move a step forward and advertise the project around the world, because it will be simply useable and there will be everything needed for a POC. Since 1 and 2 are VERY urgent, and 3 is VERY easy, I'm faithful I'll be able to advertise the project during the upcoming italian "Linux Day", on next October 28. Lucio. |
|
From: Lucio C. <lu...@su...> - 2006-09-02 21:20:39
|
Files are available for download. Enjoy. BTW, during the development I had to change the schema a bit, the new version is already online at http://dwai.sourceforge.net/schema/df.xsd . Sooner or later I will post here comments to the little changes I've made. Is there anyone here who wants to make a decent website for the project? The current site at http://dwai.sf.net is nearly awful (meaning that a few enhancements could make it become at least awful...). Lucio |
|
From: Lucio C. <lu...@su...> - 2006-09-01 21:47:30
|
Hi there, I'm here just to let you know the latest news. First of all, we have a working dewmaster script. Do you remeber what the dewmaster script should be? A script that lets you build the DF file (dwai XML) from a deb package and a bunch of additional informations. Exciting? You haven't heard anything yet! Just to say a few words about it: * it needs only bash, dpkg, and a few very common utilities (grep, sed, wc, head, tail, and so on) * it can work interactively or in batch mode * it's configurable system wide and individually for each system user * it comes with a README which contains many useful words, please read them... * it was written during my holidays in Spain, where I was lacking internet access, so it's on my notebook for now, but I'm going to release it tomorrow. You'll find the download on the sourceforge project page. * IT ROCKS! Exciting? You haven't heard anything yet! We also have a working dwai client. Yes, you have understood, exactly that little program that installs a debian package found on the web, given that the web page has a DF file for it. A few words on the dwai client: * it needs only bash and a few common utilities, just like the dewmaster script (and yes, it parses XML using only bash...) * It works like a wizard with dialog boxes. The dialog boxes are powered by whiptail, which gives the dwai client the same look and feel as the debian installer (is this a good thing?...) * It was written during my holidays, you'll find the download tomorrow * IT WORKS LIKE A CHARM! (though it's not very fast, because the bash XML library I've written it's not optimized at all, and it has a few limitations, but the warnings for the final user are already in place) These news basically mean that: * we have a nearly complete dwai solution * we need mime type integration (see package shared-mime-info) * it would be wonderful to have a debian package of the dwai client included in the upcoming stable release of Etch. Do you think we are on time? Is Etch already frozen? Are these news exciting? They are for me, I hope also for you! Lucio. |
|
From: Lucio C. <lu...@su...> - 2006-07-25 21:51:00
|
Hello buddies, I'm going to have about five weeks off, somewhere in Spain. My thrusty 486 notebook will follow me, so I should have time and tools to move a step forward with dwai. I'm also bringing my wireless card with me, but I'm not sure to find any kind of internet access, so I will likely post my progress here only after my return from the journey (semptember 3 or a few days before). In the worst case, my notebook will serve to play chess... See you, Lucio. |
|
From: Lucio C. <lu...@su...> - 2006-06-27 12:15:04
|
Hello *, I don't know if anyone noticed, but DWAI now has a "website". Head http://dwai.sf.net and you'll reach the current homepage that actually needs a bit of restyling... Writing the dewmaster code is not that easy, especially at night, so it's taking me more time than the foreseen amount: I plan to write it during my holydays in august if I won't manage to do it before. Meanwhile maybe someone here has time and skills to do a better website... |
|
From: Lucio C. <lu...@su...> - 2006-06-06 01:58:57
|
I've tried to write a full DFX that uses all the available options, While doing so I had to modify the schema to accomodate a more flexible repository line for the sources.list file (because a repository is not just a URI, but it has "deb" or "deb-src" in front of it, then a distribution and maybe other components). The final DFX is quite a long file, but it says a lot of things that would have been hard to say without XML. In natural language, it says that the debs for killer-app version 2.7.45 are available at http://debmirror.killerapp.org/debian or http://it.debmirror.killerapp.org/debian in the distro folder named "sarge" in the "main" and "contrib" sections. It also says that killer-app 2.7.45 needs a /etc/apt/preferences tuning to be installed; then it says that the debs have been tested on Sarge, Knoppix 3.4 and Agnula 1.2.1. Finally it says that the debs are likey to work on any other debian based system that can provide libc6 version 2.2 or later (or glibc version 2.2 or later) and cpp version 3.3 or older. There still one problem that we can safely ignore for the time being, but it sooner or later it will come up: the tested distribution list has no standard way to name a distribution, so for example one dewmaster could in principle name a distribution "Debian 3.1", another name it "Sarge" and another name it "Debian GNU/Linux 3.1r1 Sarge i386". Maybe we can ignore the problem forever, because the decision that the DWAI client has to take about installing the package or not can be made looking only at the dependecies and happily ignoring whatever distro the package has been tested on. In such case, the client could use the tested distro list only to show it to the user and let the user decide about what to do. Final note: seems to me that secutiry is not to take into account as long as the XSD is concerned, because digital signatures & Co. are already implemented at https protocol level (useful to guarantee DFX is authentic) and at repository level. Do you agree? Lucio. |
|
From: Lucio C. <lu...@su...> - 2006-05-18 22:19:46
|
I'm here to proudly present the first working version of the XSD and the first minimal valid DFX (short for Dwai Format XML). The last XSD I've presented had at least two problems, both in the debPackageVersionRelationshipType definition. The df.xsd attachment is the fixed version (netbeans 5 is able to understand it). The attached template.xml is the minimum valid DFX, validated by netbeans 5 against df.xsd. Please note that the minimum valid DFX requires only the package name and version, and it can be useful only when the DEW clearly warns the user that the DFX file won't touch his sources list nor his preferences. Assuming that the user already has sources list and/or preferences correctly set to install the named package, this minimal DFX can be used to launch apt by means of a single click on the web page. The only practical application I see for such a DFX is when it is used in a official distro website, such as www.debian.org. Please take a look at both files; the next step is to manually produce a number of real world DFXs, so that I have some material to build a comprehensive template for my bash dewmaster script. If you want to write some DFX you are welcome! Cheers, Lucio. |
|
From: Davide C. <dav...@re...> - 2006-05-12 11:14:36
|
Il giorno mer, 10/05/2006 alle 23.49 +0200, Lucio Crusca ha scritto: > Obviously I tried a real helloworld in python before trying the=20 > dewmaster script, and there I faced another problem: I don't like python. Eheh, I think that's not a problem. We have tons of good scripting languages :) I like python a lot, but I know its problems. > That said, if we chose python either we find someone else to code, or we = end=20 > up with a script written by a newbie which, moreover, doesn't like the=20 > language. I agree > Obviously everyone here should feel free to write its own dewmaster scrip= t in=20 > whatever language he wants, all I'm saying is that I'm going to use bash = for=20 > mine. With a set of predefined schemas (used like templates) I think bash could be the best way. --=20 Davide Corio dav...@re... Redomino S.r.l. C.so Monte Grappa 90/b - 10145 Torino - Italy Tel: +39 011 19502871 - Fax: +39 011 19791122 - http://www.redomino.com/ |
|
From: Lucio C. <lu...@su...> - 2006-05-10 21:49:51
|
It has been quite a few days since the last post... maybe you think the project is dead, but it isn't. Actually I've thought a lot about the coding of the dewmaster script, and I've faced some difficulty: while python might be a good choice for it, the problem is that I don't know python, and seems to me is not a good idea to use the dewmaster script as my helloworld in python. Obviously I tried a real helloworld in python before trying the dewmaster script, and there I faced another problem: I don't like python. That said, if we chose python either we find someone else to code, or we end up with a script written by a newbie which, moreover, doesn't like the language. Given that there are only 5 subscribers to this list, and given that it seems no one has much time to spend on this project, we have to choose a language that the coder already knows and likes. So I decided to try making the dewmaster script using bash; this has a few advantages: - I know it a bit and I like it a lot - It's a very fast way to write a dewmaster script - It's a good starting point to understand what we need to do in a more complex dewmaster script Obviously everyone here should feel free to write its own dewmaster script in whatever language he wants, all I'm saying is that I'm going to use bash for mine. My idea for the first dewmaster script is to build a very simple script that builds the XML file from the user input (readline) and a set of files, each one containing a chunk of the final XML. The logic is trivial, e.g.: ask the user the package name, take the file with the XML chunk relative to the package tag, feed it through sed to substitute some predefined string with the package name and append the result to the output file. Repeat until the user gives input. My script won't validate the output file against our XSD for now. I hope to have a working script for my next post. Cheers, Lucio. |
|
From: Lucio C. <lu...@su...> - 2006-04-03 21:42:39
|
We've forget one hopefully last thing: the DF must specify the architecture= of=20 each package. You can find below the new version of the XSD. If there is someone out there who already knows a bit o python (and I know= =20 there is at least one...hello Davide!), could he please point me to a=20 beginners guide to learn the basics and to a reference guide to browse the= =20 library? <?xml version=3D"1.0" encoding=3D"UTF-8" ?> <xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"> <!-- the debPackageNameType represents the name of a debian package as=20 understood by apt. I choose "token" as the base type because we don't want= =20 tabs, CRs and the like in a package name. --> <xs:simpleType name=3D"debPackageNameType"> =A0<xs:restriction base=3D"xs:token"/> </xs:simpleType> <!-- The same comment above fits well in debPackageVersionType --> <xs:simpleType name=3D"debPackageVersionType"> =A0<xs:restriction base=3D"xs:token"/> </xs:simpleType> <!-- Same holds true for the architecture --> <xs:simpleType name=3D"debPackageArchitectureType"> <xs:restriction base=3D"xs:token"/> </xs:simpleType> <!-- There isn't much to say here too --> <xs:simpleType name=3D"debRepositoryURIType"> =A0<xs:restriction base=3D"xs:anyURI"/> </xs:simpleType> <!-- A list of repositories assumed to be mirrors --> <xs:complexType name=3D"debRepositoryMirrorsListType"> =A0<xs:sequence> =A0 <xs:element name=3D"mirror" type=3D"debRepositoryURIType"=20 maxOccurs=3D"unbounded" /> =A0</xs:sequence> </xs:complexType> <!-- This type is used to represent any text that should be present=20 in /etc/apt/preferences for the package to be installed correctly. Here we= =20 obviously allow tabs, CRs & Co., hence "string" --> <xs:simpleType name=3D"aptPreferencesTextType"> =A0<xs:restriction base=3D"xs:string"/> </xs:simpleType> <!-- This type will be used to represent any debian flavor the deb package = is=20 designed for, such as Sarge, Etch, Knoppix 4.0.2 or Breezy 5.10. I know we= =20 should bring some sanity in the format of the flavor name, but I don't real= ly=20 know how to. We could require the flavor name to be just the same text a DC= =20 can find in /etc/issue. Any other idea?--> <xs:simpleType name=3D"debianFlavorNameType"> =A0<xs:restriction base=3D"xs:normalizedString"/> </xs:simpleType> <!-- This type is used only in dependencies lists. The deployed deb "packag= e=20 P" may depend on another "package Q *at least* version x.y.z", or on "packa= ge=20 Q *exactly* version x.y.z ", or on "package Q *at most* version x.y.z". Thi= s=20 type carries that kind of information. I'm not sure the syntax below is=20 correct. -->=20 <xs:simpleType name=3D"debPackageVersionRelationshipType"> =A0<xs:restriction base=3D"xs:token"/> =A0 =A0<xs:pattern value=3D"atmost|exactly|atleast"/> </xs:simpleType> <!-- A deb package is the union of a name, a version and an architecture --> <xs:complexType name=3D"debPackageType"> =A0<xs:sequence> =A0 <xs:element name=3D"name" type=3D"debPackageNameType"/> =A0 <xs:element name=3D"version" type=3D"debPackageVersionType"/> <xs:element name=3D"arch" type=3D"debPackageArchitectureType"/> =A0</xs:sequence> </xs:complexType> <!-- A provider type is a package and a version relationship that can satis= fy=20 a particular dependency --> <xs:complexType name=3D"dependencyProviderType"> =A0<xs:sequence> =A0 <xs:element name=3D"package" type=3D"debPackageType"/> =A0 <xs:element name=3D"versionRelationship"=20 type=3D"debPackageVersionRelationshipType"/> =A0</xs:sequence> </xs:complexType> =A0 =A0 <!-- A dependency is a list of providers where each one is an alternative t= hat=20 satisfies said dependency. Obscure? Yes! Let's try with an example: "debcon= f"=20 depends on "debconf-i18n OR debconf-english", so the dependency of debconf = is=20 a list of *two* alternative providers, namely "debconf-i18n" and=20 "debconf-english". -->=20 <xs:complexType name=3D"debPackageDependencyType"> =A0<xs:sequence> =A0 <xs:element name=3D"provider" type=3D"dependencyProviderType"=20 maxOccurs=3D"unbounded" /> =A0</xs:sequence> </xs:complexType> <!-- Finally we have the full dependencies list --> <xs:complexType name=3D"debPackageDependenciesListType"> =A0<xs:sequence> =A0 <xs:element name=3D"dependency" type=3D"debPackageDependencyType" minOc= curs=3D"0"=20 maxOccurs=3D"unbounded"/> =A0</xs:sequence> </xs:complexType> <!-- A sources list is a list of sources. Ahem, obvious, isn't it? --> <xs:complexType name=3D"debSourcesListType"> =A0<xs:sequence> =A0 <xs:element name=3D"source" type=3D"debRepositoryMirrorsListType" minOc= curs=3D"0"=20 maxOccurs=3D"unbounded"/> =A0</xs:sequence> </xs:complexType> <!-- A deployed deb package is a package available for download at the DEW.= It=20 consists of everything defined above --> <xs:complexType name=3D"deployedDebPackageType"> =A0<xs:sequence> =A0 <xs:element name=3D"package" type=3D"debPackageType"/> =A0 <xs:element name=3D"sources" type=3D"debSourcesListType" minOccurs=3D"0= " /> =A0 <xs:element name=3D"preferences" minOccurs=3D"0" maxOccurs=3D"unbounded= "=20 type=3D"aptPreferencesTextType"/> =A0 <xs:element name=3D"debianFlavor" maxOccurs=3D"unbounded"=20 type=3D"debianFlavorNameType"/> =A0 <xs:element name=3D"dependencies" maxOccurs=3D"unbounded"=20 type=3D"debPackageDependenciesListType"/> =A0 =A0</xs:sequence> </xs:complexType> <!-- the DWAI Format can handle multiple packages in a single file, and tha= t's=20 all we say with the dwayType --> <xs:complexType name=3D"dwaiType"> =A0<xs:sequence> =A0 <xs:element name=3D"dwaiEntry" type=3D"deployedDebPackageType"=20 maxOccurs=3D"unbounded"/> =A0</xs:sequence> </xs:complexType> <!-- Each XML file has one and only one root element; in this case the root= =20 element is the dwai tag --> <xs:element name=3D"dwai" type=3D"dwaiType"/> </xs:schema>=20 |
|
From: Lash <la...@em...> - 2006-04-01 19:26:22
|
Il giorno Fri, 31 Mar 2006 16:08:12 +0200 Lucio Crusca <lu...@su...> ha scritto: > > 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. [...] ok! >=20 > > 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? there is an error, packagename is instead packagename.deb. I hope it's standard. > > > 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++=20 I don't know java but i don't like it. > I'd be happy to learn Python. i'm too! > > > C++? > > It's my favourite! > What about XML? Do you know which libraries are needed for it? no :( we can use a C library if there'arent c++ libraries > >> 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=20 > 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? explode is a php function that split a string(but we can reproduce it in the language we will use), the : char is an argoument that we can give to this function for split the string returned by apt-cache so we can separete the localized string by the depend. apt-cache depends packagename however don't return the version of a depend if there is. explode function in php: array explode ( string separator, string string [, int limit] ) Returns an array of strings, each of which is a substring of string formed by splitting it on boundaries formed by the string separator. Bye --=20 Andrea Corradi | Debian User | www.debian.org Fingerprint: A41E F6B0 DBDB F04C 4940 E411 30F3 CD62 57B1 8458 gpg --keyserver keyserver.linux.it --recv-key 57B18458 Please avoid sending me Word or PowerPoint attachments. http://www.gnu.org/philosophy/no-word-attachments.html |
|
From: Lucio C. <lu...@su...> - 2006-03-31 21:40:14
|
Here I am with the revised XSD that should allow for a list of mirrors instead of a single repository. Apart from that (which ended up in a trivial modification as you can see below), another "problem" arose today in my mind: a .dwai file can contain several versions of the same package, but our XSD doesn't say that anywhere. With this XSD a dewmaster can build a perfectly valid XML .dwai file that contains completely different packages references, not only different versions of the same package. That said, I believe it's not bad to let different packages make it into the .dwai file, because it's trivial for the DC to isolate the different versions of the same package from other entirely different packages: it's enough to look at the common package names. Do you agree if we left that freedom in place? <?xml version="1.0" encoding="UTF-8" ?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <!-- the debPackageNameType represents the name of a debian package as understood by apt. I choose "token" as the base type because we don't want tabs, CRs and the like in a package name. --> <xs:simpleType name="debPackageNameType"> <xs:restriction base="xs:token"/> </xs:simpleType> <!-- The same comment above fits well in debPackageVersionType --> <xs:simpleType name="debPackageVersionType"> <xs:restriction base="xs:token"/> </xs:simpleType> <!-- There isn't much to say here too --> <xs:simpleType name="debRepositoryURIType"> <xs:restriction base="xs:anyURI"/> </xs:simpleType> <!-- A list of repositories assumed to be mirrors --> <xs:complexType name="debRepositoryMirrorsListType"> <xs:sequence> <xs:element name="mirror" type="debRepositoryURIType" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <!-- This type is used to represent any text that should be present in /etc/apt/preferences for the package to be installed correctly. Here we obviously allow tabs, CRs & Co., hence "string" --> <xs:simpleType name="aptPreferencesTextType"> <xs:restriction base="xs:string"/> </xs:simpleType> <!-- This type will be used to represent any debian flavor the deb package is designed for, such as Sarge, Etch, Knoppix 4.0.2 or Breezy 5.10. I know we should bring some sanity in the format of the flavor name, but I don't really know how to. We could require the flavor name to be just the same text a DC can find in /etc/issue. Any other idea?--> <xs:simpleType name="debianFlavorNameType"> <xs:restriction base="xs:normalizedString"/> </xs:simpleType> <!-- This type is used only in dependencies lists. The deployed deb "package P" may depend on another "package Q *at least* version x.y.z", or on "package Q *exactly* version x.y.z ", or on "package Q *at most* version x.y.z". This type carries that kind of information. I'm not sure the syntax below is correct. --> <xs:simpleType name="debPackageVersionRelationshipType"> <xs:restriction base="xs:token"/> <xs:pattern value="atmost|exactly|atleast"/> </xs:simpleType> <!-- A deb package is the union of a name and a version --> <xs:complexType name="debPackageType"> <xs:sequence> <xs:element name="name" type="debPackageNameType"/> <xs:element name="version" type="debPackageVersionType"/> </xs:sequence> </xs:complexType> <!-- A provider type is a package and a version relationship that can satisfy a particular dependency --> <xs:complexType name="dependencyProviderType"> <xs:sequence> <xs:element name="package" type="debPackageType"/> <xs:element name="versionRelationship" type="debPackageVersionRelationshipType"/> </xs:sequence> </xs:complexType> <!-- A dependency is a list of providers where each one is an alternative that satisfies said dependency. Obscure? Yes! Let's try with an example: "debconf" depends on "debconf-i18n OR debconf-english", so the dependency of debconf is a list of *two* alternative providers, namely "debconf-i18n" and "debconf-english". --> <xs:complexType name="debPackageDependencyType"> <xs:sequence> <xs:element name="provider" type="dependencyProviderType" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <!-- Finally we have the full dependencies list --> <xs:complexType name="debPackageDependenciesListType"> <xs:sequence> <xs:element name="dependency" type="debPackageDependencyType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <!-- A sources list is a list of sources. Ahem, obvious, isn't it? --> <xs:complexType name="debSourcesListType"> <xs:sequence> <xs:element name="source" type="debRepositoryMirrorsListType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <!-- A deployed deb package is a package available for download at the DEW. It consists of everything defined above --> <xs:complexType name="deployedDebPackageType"> <xs:sequence> <xs:element name="package" type="debPackageType"/> <xs:element name="sources" type="debSourcesListType" minOccurs="0" /> <xs:element name="preferences" minOccurs="0" maxOccurs="unbounded" type="aptPreferencesTextType"/> <xs:element name="debianFlavor" maxOccurs="unbounded" type="debianFlavorNameType"/> <xs:element name="dependencies" maxOccurs="unbounded" type="debPackageDependenciesListType"/> </xs:sequence> </xs:complexType> <!-- the DWAI Format can handle multiple packages in a single file, and that's all we say with the dwayType --> <xs:complexType name="dwaiType"> <xs:sequence> <xs:element name="dwaiEntry" type="deployedDebPackageType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <!-- Each XML file has one and only one root element; in this case the root element is the dwai tag --> <xs:element name="dwai" type="dwaiType"/> </xs:schema> |
|
From: Lucio C. <lu...@su...> - 2006-03-31 14:08:40
|
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? |
|
From: Lash <la...@em...> - 2006-03-30 22:46:36
|
Il giorno Fri, 31 Mar 2006 00:17:04 +0200 Lucio Crusca <lu...@su...> ha scritto: > I wrote: > > Now the question is: what should we use to write the > > dewmaster script? >=20 > Actually there is another question: how do we get the dependencies > list from a deb package?=20 > Choices: > 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 --=20 Andrea Corradi | Debian User | www.debian.org Fingerprint: A41E F6B0 DBDB F04C 4940 E411 30F3 CD62 57B1 8458 gpg --keyserver keyserver.linux.it --recv-key 57B18458 Please avoid sending me Word or PowerPoint attachments. http://www.gnu.org/philosophy/no-word-attachments.html |
|
From: Lash <la...@em...> - 2006-03-30 22:37:51
|
Il giorno Thu, 30 Mar 2006 00:34:14 +0200 Lucio Crusca <lu...@su...> ha scritto: > 1) this should be a script that takes as arguments: > 1.1 - the .deb package(s) > 1.2 - the repository(ies) URL(s) (optional but recommended) why the repository's URL is optional?? he objective of dawi isnt add the repository URL to source.list file? > Dependency info must be taken from the .deb package and put in the > XML DF file. why we take the dependecy?? if we install the package with apt! > I don't know if it's possible to extract the dependency > info from a .deb with some dpkg magic, with a parse of dpkg -I package_name with bash-script: 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 > What about Python? It's ok > What about Java No! please > C++? It's my favourite! I have no mach time to spent in dwai but i'm intressed to it --=20 Andrea Corradi | Debian User | www.debian.org Fingerprint: A41E F6B0 DBDB F04C 4940 E411 30F3 CD62 57B1 8458 gpg --keyserver keyserver.linux.it --recv-key 57B18458 Please avoid sending me Word or PowerPoint attachments. http://www.gnu.org/philosophy/no-word-attachments.html |
|
From: Lucio C. <lu...@su...> - 2006-03-30 22:17:13
|
I wrote:
> Now the question is: what should we use to write the
> dewmaster script?
Actually there is another question: how do we get the dependencies list from a
deb package?
Choices:
1 - Reading the ar format directly (not that wise in my opinion unless we know
the .deb ar format won't change frequently)
2 - using "apt-cache depends" (quite messy because its output is mixed with
localized strings, hence unpredictable; moreover apt-cache requires the deb
to be reachable through sources.list, which may not be the case)
3 - dpkg-query --show <pkg> --showformat=\${Depends} (a little better than
apt-cache, but still the package must be reachable through sources.list,
which may lead to the need of a dedicated system only to build DWAI XML
files)
Any other suggestion?
|
|
From: Lucio C. <lu...@su...> - 2006-03-30 21:16:04
|
Davide Corio wrote: > Il giorno gio, 30/03/2006 alle 00.34 +0200, Lucio Crusca ha scritto: > > 1 - provide tools for DEWmasters to help them build the XML DF file given > > Are you thinking something similar to dpkg-scanpackages? I didn't know dpkg-scanpackages until now. I've took a look at its manpages and it seems it does a work similar to what our script should do. In order to make it clear what I have in mind, I give an example, where dewmaster is the name of our script jul...@ww...:~/debs$ ls wine-0.9.10-2.deb jul...@ww...:~/debs$ dewmaster --interactive Gimme deb package file plz: wine-0.9* Do u want to include sources.list stuff in XML? y Gimme comma separated sources plz: deb http://... D'ya need preferences by any chance? n Designed for? Sid Output file name? wine.dwai That's all, building wine.dwai XML file. Extracting dependecies from wine-0.9.10-2.deb... done. Your dwai file is ready. You probably want to move it under /var/www jul...@ww...:~/debs$ su -c mv wine.dwai /var/www/download/dew/ Needless to say, dewmaster script must be able to work also in non interactive batch mode, taking all the input from a configuration file and/or command line. Now the question is: what should we use to write the dewmaster script? |