:: Re: [DNG] Packaging Vdev
Top Page
Delete this message
Reply to this message
Author: Daniel Reurich
Date:  
To: dng
Subject: Re: [DNG] Packaging Vdev
- cut for brevity
>>
>> I'm just stating that I disagree with your premise that creating a
>> package that breaks policy is acceptable "until you can get it to work".
>>
>> If vdev doesn't work already then it's to early to be packaging it.
>> However indications are that it does work and thus it should be
>> properly packaged.
>>
>> As for testing it should minimally be able to be used successfully
>> debootstrap a new system and also to replace udev on a running system
>> without seriously breaking anything.
>>
>> Once it does that we should put it in experimental for wider testing.
>>
>
>     Daniel, my point was just practical, although it's obviously Aitor's
> buzyness.

>
>     Jude organized his install process so as to put the files under
> /usr/local, so that testers could easily test it without interferring
> with the hotplugger in function. As such, the package does not need to
> exclude Udev.  I tested Vdev with the normal file hierarchy, in a tiny
> OS Busybox-based, and I didn't read any report of anyone else having
> done so.


Right... so only you and presumably Jude have done any real testing of this.
>
>     Several months ago, when I stopped testing Vdev in this way, it was
> working fine. But the latest version isn't working properly and I don't
> know the reason. I cannot exclude that the reason is in handling the
> file hierarchy. Vdev manages a lot of files, much more than Udev. OTOH I
> didn't read any report of a successful test of this latest version under
> /usr/local.


Ok. So obviously this needs fixing first before even consider building
a package. Any idea what last version actually built correctly and
worked? That would be a good starting point.
>
>     This is why I suggested to go step by step and not build blindly a
> final version of the package which would force the removal of Udev and
> replace it with something which doesn't work. But,
> again, this was just a friendly suggestion to Aitor, who probably
> doesn't need it. And this suggestion caused a useless discussion which
> is why I regret to have made it.


Don't regret the comment. I agree that there is little point in putting
effort into packaging something that isn't currently in a functional
state. If you could share the details of your testing so people can
replicate and perhaps help with the development that would mean that
this discussion has not been useless, but instead useful in teasing out
details that at least I had previously missed.

Thank you for this vital update Didier ;-)

--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722