From info at sten-net.de Thu Sep 1 21:56:58 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Thu, 01 Sep 2005 21:56:58 +0200 Subject: [Installit-dev] XML validation Message-ID: <43175D0A.3000301@sten-net.de> Hey all, I worked on Parsers for the mirror list and the package list last days. I tried to replace DTD validation by a "smarter" solution which just skipped invalid mirrors/packages/groups etc. But this makes the code almost unreadable (even if you move logging messages etc. into separate methods) so I suggest we should at least depend on PyXML (http://pyxml.sf.net). It's the most common XML toolkit for Python and should be available for all platforms. We'll be doing heavy XML parsing/writing stuff and we need to perform proper validation in order to detect errors in the XML formats as early as possible. Another idea would be to just rely on the mirror maintainers/packagers to provide valid file and just raise Exceptions if something's not correct. What do you think about it? - Jannis From info at sten-net.de Thu Sep 1 21:59:09 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Thu, 01 Sep 2005 21:59:09 +0200 Subject: [Installit-dev] XML validation In-Reply-To: <43175D0A.3000301@sten-net.de> References: <43175D0A.3000301@sten-net.de> Message-ID: <43175D8D.1050600@sten-net.de> Jannis Pohlmann schrieb: > Hey all, > > I worked on Parsers for the mirror list and the package list last days. > I tried to replace DTD validation by a "smarter" solution which just > skipped invalid mirrors/packages/groups etc. But this makes the code > almost unreadable (even if you move logging messages etc. into separate > methods) so I suggest we should at least depend on PyXML > (http://pyxml.sf.net). It's the most common XML toolkit for Python and > should be available for all platforms. > > We'll be doing heavy XML parsing/writing stuff and we need to perform > proper validation in order to detect errors in the XML formats as early > as possible. > > Another idea would be to just rely on the mirror maintainers/packagers > to provide valid file and just raise Exceptions if something's not correct. > > What do you think about it? > > - Jannis > _______________________________________________ > Installit-dev mailing list > Installit-dev at xfce.org > http://foo-projects.org/mailman/listinfo/installit-dev > > Uh, lots of mistakes in that one. Guess I'm already too tired to write ... From info at sten-net.de Wed Sep 7 18:53:26 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 07 Sep 2005 18:53:26 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C644B.8090700@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C644B.8090700@unix-ag.uni-siegen.de> Message-ID: <431F1B06.6090203@sten-net.de> Hey Benny, Benedikt Meurer schrieb: > Use kill($PID, 0) rather than /proc/$PID and you're ok. Trust me, it's > really not worth the trouble with fcntl()/lockf() locking. And we're not > developing a critical database, so if a user manages to start two > instances of InstallIt, then he'll run into trouble and may remember to > read the documentation when he uses a software next time. ;-) i tried this (it's in SVN, see Core/LockFile and i2t for the usage). It doesn't really work at all. What did you expect it to do? Regards, Jannis From benedikt.meurer at unix-ag.uni-siegen.de Thu Sep 8 17:13:31 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Thu, 08 Sep 2005 17:13:31 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <431F1B06.6090203@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C644B.8090700@unix-ag.uni-siegen.de> <431F1B06.6090203@sten-net.de> Message-ID: <4320551B.3000802@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: >>Use kill($PID, 0) rather than /proc/$PID and you're ok. Trust me, it's >>really not worth the trouble with fcntl()/lockf() locking. And we're not >>developing a critical database, so if a user manages to start two >>instances of InstallIt, then he'll run into trouble and may remember to >>read the documentation when he uses a software next time. ;-) > > i tried this (it's in SVN, see Core/LockFile and i2t for the usage). It > doesn't really work at all. What did you expect it to do? Just checked it. Seems to work fine, except that you still use /proc instead of kill(). > Regards, > Jannis Benedikt From benedikt.meurer at unix-ag.uni-siegen.de Thu Sep 8 17:15:34 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Thu, 08 Sep 2005 17:15:34 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <4320551B.3000802@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C644B.8090700@unix-ag.uni-siegen.de> <431F1B06.6090203@sten-net.de> <4320551B.3000802@unix-ag.uni-siegen.de> Message-ID: <43205596.8050607@unix-ag.uni-siegen.de> Benedikt Meurer wrote: > Jannis Pohlmann wrote: > >>>Use kill($PID, 0) rather than /proc/$PID and you're ok. Trust me, it's >>>really not worth the trouble with fcntl()/lockf() locking. And we're not >>>developing a critical database, so if a user manages to start two >>>instances of InstallIt, then he'll run into trouble and may remember to >>>read the documentation when he uses a software next time. ;-) >> >>i tried this (it's in SVN, see Core/LockFile and i2t for the usage). It >>doesn't really work at all. What did you expect it to do? > > > Just checked it. Seems to work fine, except that you still use /proc > instead of kill(). And you shouldn't use negative exit codes, as on some platforms, that may not only affect the exit code, but also the additional exit status flags, which is certainly not what you want. Try to limit yourself to the exit codes from 0 to 126. Benedikt From info at sten-net.de Thu Sep 8 18:00:38 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Thu, 08 Sep 2005 18:00:38 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <43205596.8050607@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C644B.8090700@unix-ag.uni-siegen.de> <431F1B06.6090203@sten-net.de> <4320551B.3000802@unix-ag.uni-siegen.de> <43205596.8050607@unix-ag.uni-siegen.de> Message-ID: <43206026.4090908@sten-net.de> Hey Benny, Benedikt Meurer schrieb: > Benedikt Meurer wrote: > >>Jannis Pohlmann wrote: >> >> >>>>Use kill($PID, 0) rather than /proc/$PID and you're ok. Trust me, it's >>>>really not worth the trouble with fcntl()/lockf() locking. And we're not >>>>developing a critical database, so if a user manages to start two >>>>instances of InstallIt, then he'll run into trouble and may remember to >>>>read the documentation when he uses a software next time. ;-) >>> >>>i tried this (it's in SVN, see Core/LockFile and i2t for the usage). It >>>doesn't really work at all. What did you expect it to do? >> >> >>Just checked it. Seems to work fine, except that you still use /proc >>instead of kill(). yes, I commented out the kill() thing for one reason: It didn't do anything useful. I asked myself what you could have meant by suggesting kill() and came to the conclusion that your intend was to kill the running instance before starting the new one, right? Well, I'd prefer aborting the program if another instance already is running. I couldn't find a platform-independent way for determining if a process with a certain PID is running or not, this is why I used /proc. I'm still not sure about this, perhaps fcntl/lockf is better anyway. > > > And you shouldn't use negative exit codes, as on some platforms, that > may not only affect the exit code, but also the additional exit status > flags, which is certainly not what you want. Try to limit yourself to > the exit codes from 0 to 126. Yep, thought about that, too. I have to look into what the different exit codes mean and use those which make sense. - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Thu Sep 8 18:12:14 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Thu, 08 Sep 2005 18:12:14 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <43206026.4090908@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C644B.8090700@unix-ag.uni-siegen.de> <431F1B06.6090203@sten-net.de> <4320551B.3000802@unix-ag.uni-siegen.de> <43205596.8050607@unix-ag.uni-siegen.de> <43206026.4090908@sten-net.de> Message-ID: <432062DE.8000000@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: >>>>>Use kill($PID, 0) rather than /proc/$PID and you're ok. Trust me, it's >>>>>really not worth the trouble with fcntl()/lockf() locking. And we're not >>>>>developing a critical database, so if a user manages to start two >>>>>instances of InstallIt, then he'll run into trouble and may remember to >>>>>read the documentation when he uses a software next time. ;-) >>>> >>>>i tried this (it's in SVN, see Core/LockFile and i2t for the usage). It >>>>doesn't really work at all. What did you expect it to do? >>> >>> >>>Just checked it. Seems to work fine, except that you still use /proc >>>instead of kill(). > > yes, I commented out the kill() thing for one reason: It didn't do > anything useful. I asked myself what you could have meant by suggesting > kill() and came to the conclusion that your intend was to kill the > running instance before starting the new one, right? Well, I'd prefer > aborting the program if another instance already is running. > > I couldn't find a platform-independent way for determining if a process > with a certain PID is running or not, this is why I used /proc. I'm > still not sure about this, perhaps fcntl/lockf is better anyway. The platform independent way is to use kill(pid, 0). 0 is a special signal, that is not delivered to the target process, but is handled by the kernel completely. The kernel will check if the process with the given pid is still alive and if so, respond with 0, else it responds with an error, telling you that the process is gone (or you don't have permission to talk to the process). > - Jannis Benedikt From info at sten-net.de Thu Sep 8 18:20:43 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Thu, 08 Sep 2005 18:20:43 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <432062DE.8000000@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C644B.8090700@unix-ag.uni-siegen.de> <431F1B06.6090203@sten-net.de> <4320551B.3000802@unix-ag.uni-siegen.de> <43205596.8050607@unix-ag.uni-siegen.de> <43206026.4090908@sten-net.de> <432062DE.8000000@unix-ag.uni-siegen.de> Message-ID: <432064DB.3020304@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>>>>>Use kill($PID, 0) rather than /proc/$PID and you're ok. Trust me, it's >>>>>>really not worth the trouble with fcntl()/lockf() locking. And we're not >>>>>>developing a critical database, so if a user manages to start two >>>>>>instances of InstallIt, then he'll run into trouble and may remember to >>>>>>read the documentation when he uses a software next time. ;-) >>>>> >>>>>i tried this (it's in SVN, see Core/LockFile and i2t for the usage). It >>>>>doesn't really work at all. What did you expect it to do? >>>> >>>> >>>>Just checked it. Seems to work fine, except that you still use /proc >>>>instead of kill(). >> >>yes, I commented out the kill() thing for one reason: It didn't do >>anything useful. I asked myself what you could have meant by suggesting >>kill() and came to the conclusion that your intend was to kill the >>running instance before starting the new one, right? Well, I'd prefer >>aborting the program if another instance already is running. >> >>I couldn't find a platform-independent way for determining if a process >>with a certain PID is running or not, this is why I used /proc. I'm >>still not sure about this, perhaps fcntl/lockf is better anyway. > > > The platform independent way is to use kill(pid, 0). 0 is a special > signal, that is not delivered to the target process, but is handled by > the kernel completely. The kernel will check if the process with the > given pid is still alive and if so, respond with 0, else it responds > with an error, telling you that the process is gone (or you don't have > permission to talk to the process). Okay, fixed. I'll commit it later this day. Regards, Jannis From info at sten-net.de Mon Sep 19 19:13:57 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Mon, 19 Sep 2005 19:13:57 +0200 Subject: [Installit-dev] Package categories Message-ID: <432EF1D5.8020906@sten-net.de> Hi all, I've thought long wether we should add categories the package list or not ... well, I think we should. I also rethought Benny's idea of a tree structure for listing the packages which I absolutely refused at first. The question now is how far we go. Basically, I'd suggest to use a rather simple XML structure for the package list: ... Here, the internal name of the group would be the same as it's displayed title. Another idea would be to use a element: or The last idea which comes to my mind would be a separate groups.xml file. But in my opinion this would only make maintaining more difficult. We also should not use nested categories, this just made everything unnecessarily complex. And - most probably - a directory structure representing the category structure (like /files/file-management, /files/xfce-libraries etc.) isn't a good idea as well. Categories should just be used to list the packages in a more user-friendly and concise way. How do you think about this topic? Regards, Jannis From info at sten-net.de Mon Sep 19 19:21:05 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Mon, 19 Sep 2005 19:21:05 +0200 Subject: [Installit-dev] Package categories In-Reply-To: <432EF1D5.8020906@sten-net.de> References: <432EF1D5.8020906@sten-net.de> Message-ID: <432EF381.4080605@sten-net.de> Oh well, I've worked so much on other things that I didn't remember we already have "groups". Well, groups should be listed side by side with (and on top of) categories as they are more than packages. Listing could look like this: - Groups Xfce 4.3 Xfce 4.2.2 + Xfce Libraries - File Management Thunar Xffm + Xfce Panel Plugins . . . Okay? Regards, Jannis From benedikt.meurer at unix-ag.uni-siegen.de Mon Sep 19 19:47:36 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Mon, 19 Sep 2005 19:47:36 +0200 Subject: [Installit-dev] Package categories In-Reply-To: <432EF381.4080605@sten-net.de> References: <432EF1D5.8020906@sten-net.de> <432EF381.4080605@sten-net.de> Message-ID: <432EF9B8.9040100@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: > Oh well, I've worked so much on other things that I didn't remember we > already have "groups". Well, groups should be listed side by side with > (and on top of) categories as they are more than packages. Listing could > look like this: > > - Groups > Xfce 4.3 > Xfce 4.2.2 > + Xfce Libraries > - File Management > Thunar > Xffm > + Xfce Panel Plugins > . > . > . > > Okay? Looks good. > Regards, > Jannis Benedikt From info at sten-net.de Tue Sep 20 12:32:27 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Tue, 20 Sep 2005 12:32:27 +0200 Subject: [Installit-dev] Package categories In-Reply-To: <432EF1D5.8020906@sten-net.de> References: <432EF1D5.8020906@sten-net.de> Message-ID: <432FE53B.2000303@sten-net.de> Morning, ok, this is my new suggestion for the package list format. ... ... ... NOTES: 1. Removed the version attribute from group. This should be put into the title. 2. Renamed the name attribute to title for consistency reasons. 3. The type attribute for packages and groups is optional. If a group has a type attribute the type of its members is supposed to be the same. 4. Packages can only be member of *one* category. Anything else would force the user to be confused, hehe. Please tell me what you think of it. Regards, Jannis From info at sten-net.de Tue Sep 20 12:36:26 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Tue, 20 Sep 2005 12:36:26 +0200 Subject: [Installit-dev] Package categories In-Reply-To: <432FE53B.2000303@sten-net.de> References: <432EF1D5.8020906@sten-net.de> <432FE53B.2000303@sten-net.de> Message-ID: <432FE62A.3000908@sten-net.de> Jannis Pohlmann schrieb: > Morning, > > ok, this is my new suggestion for the package list format. > > > > > > > ... > > > > > > > ... > > > > > > > > > ... > > > Ah, yes and this would be displayed this way: - Groups * Thunar 1.0 * Xfce 4.3 - File Management * thunar - Package Management * installit - Xfce Libraries * libexo * xfce4utils The names "thunar", "installit", "libexo" and "xfce4utils" will be replaced with the element of their header/control file. - Jannis From info at sten-net.de Tue Sep 20 13:04:05 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Tue, 20 Sep 2005 13:04:05 +0200 Subject: [Installit-dev] Header file format Message-ID: <432FECA5.2030208@sten-net.de> Hi all. I worked out a slightly enhanced version of the header file format. Have a look at it at http://installit.xfce.org/trac.cgi/wiki/HeaderFile What's your opinion about it? Regards, Jannis From benedikt.meurer at unix-ag.uni-siegen.de Tue Sep 20 13:36:13 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Tue, 20 Sep 2005 13:36:13 +0200 Subject: [Installit-dev] Header file format In-Reply-To: <432FECA5.2030208@sten-net.de> References: <432FECA5.2030208@sten-net.de> Message-ID: <432FF42D.9010005@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: > Hi all. > > I worked out a slightly enhanced version of the header file format. Have > a look at it at http://installit.xfce.org/trac.cgi/wiki/HeaderFile > > What's your opinion about it? I'd suggest a different way for the stages: <stages> <configure scheme="gnu-autoconf" /> <build scheme="gnu-make" /> <install scheme="gnu-make" /> </stages> with hooks for the different schemes (e.g. pre and post hooks): <pre-hook stage="install" scheme="gnu-autoconf"> <cmd>echo narf > narf</cmd> </pre-hook> <hook stage="install" scheme="gnu-make"> <cmd>${GNUMAKE} install</cmd> </hook> <post-hook stage="install" scheme="gnu-make"> <cmd>${BSDINSTALL} -c foo ${PREFIX}/etc/foo</cmd> </post-hook> And some of the hooks are predefined hooks, while the maintainer is still able to override existing hooks or introduce new hooks (well, hooks is probably not the best term here, how about "action", "pre-action" and "post-action"?). > Regards, > Jannis Benedikt From info at sten-net.de Tue Sep 20 14:11:37 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Tue, 20 Sep 2005 14:11:37 +0200 Subject: [Installit-dev] Header file format In-Reply-To: <432FF42D.9010005@unix-ag.uni-siegen.de> References: <432FECA5.2030208@sten-net.de> <432FF42D.9010005@unix-ag.uni-siegen.de> Message-ID: <432FFC79.2020102@sten-net.de> Hey Benny, Benedikt Meurer schrieb: > I'd suggest a different way for the stages: > > <stages> > <configure scheme="gnu-autoconf" /> > <build scheme="gnu-make" /> > <install scheme="gnu-make" /> > </stages> > > with hooks for the different schemes (e.g. pre and post hooks): > > <pre-hook stage="install" scheme="gnu-autoconf"> > <cmd>echo narf > narf</cmd> > </pre-hook> > > <hook stage="install" scheme="gnu-make"> > <cmd>${GNUMAKE} install</cmd> > </hook> > > <post-hook stage="install" scheme="gnu-make"> > <cmd>${BSDINSTALL} -c foo ${PREFIX}/etc/foo</cmd> > </post-hook> I think we could leave out the <cmd/> element here. > And some of the hooks are predefined hooks, while the maintainer is > still able to override existing hooks or introduce new hooks (well, > hooks is probably not the best term here, how about "action", > "pre-action" and "post-action"?). Sounds quite good. Additionally, we should make the configure and build stages optional since they're not needed for (most) binaries. For DPKG (or DEB?) this would just be: <stages> <install scheme="DPKG"/> </stages> <!-- Pre-defined DPKG scheme implemented in InstallIt: --> <action stage="install" scheme="DPKG"> dpkg --install ${FILE} </action> Substitutions like ${GNUMAKE}, ${BSDINSTALL}, ${PREFIX} and ${FILE} would be provided by InstallIt, then. Right? - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Tue Sep 20 14:38:33 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Tue, 20 Sep 2005 14:38:33 +0200 Subject: [Installit-dev] Header file format In-Reply-To: <432FFC79.2020102@sten-net.de> References: <432FECA5.2030208@sten-net.de> <432FF42D.9010005@unix-ag.uni-siegen.de> <432FFC79.2020102@sten-net.de> Message-ID: <433002C9.1000904@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: > Hey Benny, > > Benedikt Meurer schrieb: > >>I'd suggest a different way for the stages: >> >><stages> >> <configure scheme="gnu-autoconf" /> >> <build scheme="gnu-make" /> >> <install scheme="gnu-make" /> >></stages> >> >>with hooks for the different schemes (e.g. pre and post hooks): >> >><pre-hook stage="install" scheme="gnu-autoconf"> >> <cmd>echo narf > narf</cmd> >></pre-hook> >> >><hook stage="install" scheme="gnu-make"> >> <cmd>${GNUMAKE} install</cmd> >></hook> >> >><post-hook stage="install" scheme="gnu-make"> >> <cmd>${BSDINSTALL} -c foo ${PREFIX}/etc/foo</cmd> >></post-hook> > > > I think we could leave out the <cmd/> element here. > > >>And some of the hooks are predefined hooks, while the maintainer is >>still able to override existing hooks or introduce new hooks (well, >>hooks is probably not the best term here, how about "action", >>"pre-action" and "post-action"?). > > > Sounds quite good. Additionally, we should make the configure and build > stages optional since they're not needed for (most) binaries. > > For DPKG (or DEB?) this would just be: > > <stages> > <install scheme="DPKG"/> > </stages> > > <!-- Pre-defined DPKG scheme implemented in InstallIt: --> > <action stage="install" scheme="DPKG"> > dpkg --install ${FILE} > </action> > > Substitutions like ${GNUMAKE}, ${BSDINSTALL}, ${PREFIX} and ${FILE} > would be provided by InstallIt, then. Right? Yes. But we should permit the maintainer to add additional variables, similar to ant. > - Jannis Benedikt From info at sten-net.de Tue Sep 20 14:41:07 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Tue, 20 Sep 2005 14:41:07 +0200 Subject: [Installit-dev] Header file format In-Reply-To: <433002C9.1000904@unix-ag.uni-siegen.de> References: <432FECA5.2030208@sten-net.de> <432FF42D.9010005@unix-ag.uni-siegen.de> <432FFC79.2020102@sten-net.de> <433002C9.1000904@unix-ag.uni-siegen.de> Message-ID: <43300363.1030104@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>Hey Benny, >> >>Benedikt Meurer schrieb: >> >> >>>I'd suggest a different way for the stages: >>> >>><stages> >>> <configure scheme="gnu-autoconf" /> >>> <build scheme="gnu-make" /> >>> <install scheme="gnu-make" /> >>></stages> >>> >>>with hooks for the different schemes (e.g. pre and post hooks): >>> >>><pre-hook stage="install" scheme="gnu-autoconf"> >>> <cmd>echo narf > narf</cmd> >>></pre-hook> >>> >>><hook stage="install" scheme="gnu-make"> >>> <cmd>${GNUMAKE} install</cmd> >>></hook> >>> >>><post-hook stage="install" scheme="gnu-make"> >>> <cmd>${BSDINSTALL} -c foo ${PREFIX}/etc/foo</cmd> >>></post-hook> >> >> >>I think we could leave out the <cmd/> element here. >> >> >> >>>And some of the hooks are predefined hooks, while the maintainer is >>>still able to override existing hooks or introduce new hooks (well, >>>hooks is probably not the best term here, how about "action", >>>"pre-action" and "post-action"?). >> >> >>Sounds quite good. Additionally, we should make the configure and build >>stages optional since they're not needed for (most) binaries. >> >>For DPKG (or DEB?) this would just be: >> >> <stages> >> <install scheme="DPKG"/> >> </stages> >> >> <!-- Pre-defined DPKG scheme implemented in InstallIt: --> >> <action stage="install" scheme="DPKG"> >> dpkg --install ${FILE} >> </action> >> >>Substitutions like ${GNUMAKE}, ${BSDINSTALL}, ${PREFIX} and ${FILE} >>would be provided by InstallIt, then. Right? > > > Yes. But we should permit the maintainer to add additional variables, > similar to ant. Good idea. I will add this to the header file format draft immediately. - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Tue Sep 20 18:15:01 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Tue, 20 Sep 2005 18:15:01 +0200 Subject: [Installit-dev] Package categories In-Reply-To: <432FE53B.2000303@sten-net.de> References: <432EF1D5.8020906@sten-net.de> <432FE53B.2000303@sten-net.de> Message-ID: <43303585.6070507@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: > Morning, > > ok, this is my new suggestion for the package list format. > > <packages> > <categories> > <category title="Xfce Libraries" name="xfce-libs"/> > <category title="File Management" name="file-management"/> > <category title="Package Management" name="pkg-management"/> > ... > </categories > > <package name="thunar" version="1.0" category="file-management"/> > <package name="libexo" version="0.9" category="xfce-libs"/> > <package name="libexo" version="1.0" category="xfce-libs"/> > <package name="xfce4utils" version="4.3" category="xfce-libs"/> > <package name="installit" version="0.9" category="pkg-management"/> > ... > > <group title="Thunar 1.0"> > <member name="thunar" version="1.0"/> > <member name="libexo" version="1.0"/> > </group> > > <group title="Xfce 4.3"> > <member name="xfce4utils" version="4.3"/> > ... > </group> > </packages> > > NOTES: > > 1. Removed the version attribute from group. This should be put into > the title. > > 2. Renamed the name attribute to title for consistency reasons. > > 3. The type attribute for packages and groups is optional. If a group > has a type attribute the type of its members is supposed to be the > same. > > 4. Packages can only be member of *one* category. Anything else would > force the user to be confused, hehe. > > Please tell me what you think of it. Again, looks good. > Regards, > Jannis Benedikt