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: