:: Re: [DNG] Packaging Vdev
Forside
Slet denne besked
Besvar denne besked
Skribent: Didier Kryn
Dato:  
Til: dng
Emne: Re: [DNG] Packaging Vdev
Le 19/03/2016 22:00, Daniel Reurich a écrit :
>
> On 20 March 2016 9:07:48 AM NZDT, Didier Kryn <kryn@???> wrote:
>> Le 19/03/2016 21:01, Daniel Reurich a écrit :
>>> On 20/03/16 08:56, Didier Kryn wrote:
>>>>> Le 19/03/2016 19:05, aitor_czr a écrit :
>>>>>>> Hi all,
>>>>>>>
>>>>>>> By default, PSTAT (a dependency of VDEV) is installed in
>> "/usr/local",
>>>>>>> just as VDEV.
>>>>>>>
>>>>>>> As Daniel Raurich explained in another thread:
>>>>>>>
>>>>>>> [...] the "/usr/local" directory is for non-packaged local stuff
>> [...]
>>>>>>> So, should i change this configuration for those packages, or
>> should i
>>>>>>> skip debhelper's "dh_usrlocal" script adding:
>>>>>>>
>>>>>>> binary:
>>>>>>>      dh binary --before dh_usrlocal
>>>>>>>      dh binary --after dh_usrlocal

>>>>>>>
>>>>>>> to debian/rules?
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>>     Aitor.

>>>>>>>
>>>>>>>
>>>>>      Jude organized the package like this for people to test it on
>>>>> running systems without interfering with the existing hotplugger.
>> Vdev
>>>>> would create device files and other descriptive files under
>>>>> /usr/local/dev. But, of course it was not meant to remain like this
>> if
>>>>> Vdev was to be the hotplugger in charge.

>>>>>
>>>>>      If it's worth, you might leave it like this until you can get
>> it to
>>>>> work and then switch to a normal file hierarchy when ready.

>>>>>
>>> I strongly disagree. If it's to be packaged, it should be packaged
>>> properly in keeping with Debian policies (which Devuan has adopted)
>> with
>>> regards to FHS and location of parts.
>>>
>>> Vdev being an essential system tool should be in the root hierarchy.
>>      I fully agree with you; therefore I don't understand in what you
>> disagree :-)

>>
> You were just suggesting that it would be ok to "leave it like this until you can get
> it to work and then switch to a normal file hierarchy when ready".
>
> 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.


     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.


     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.


     Didier