Hi again,
On 03/20/2016 09:08 AM, Didier Kryn <[email protected]> wrote:
Le 19/03/2016 22:00, Daniel Reurich a écrit :
>
>On 20 March 2016 9:07:48 AM NZDT, Didier Kryn<[email protected]> 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
Ok, being my first atempt, i will respect Jude Nelson's original
location in "/usr/local" and leave this point for later. Debian's policy
isn't a priority now. This also will make the job easier. So, for the
time being, i will skip dh_usrlocal with [*]:
binary:
dh binary --before dh_usrlocal
dh binary --after dh_usrlocal
After testing the packages, we will take up this discussion again, if it's
agreeable to you.
Thanks to all of you,
Aitor.
[*] Rainer Weikusat (Dng Digest, Vol 11, Issue 86)
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
