:: Re: [DNG] vdev packaging
Forside
Slet denne besked
Besvar denne besked
Skribent: Hendrik Boom
Dato:  
Til: dng
Emne: Re: [DNG] vdev packaging
On Sat, Aug 27, 2016 at 08:45:35AM +1000, Ralph Ronnquist wrote:
>
>
> shraptor wrote on 27/08/16 02:08:
> >On 2016-08-26 17:41, shraptor wrote:
> >>On 2016-08-25 14:06, Ralph Ronnquist wrote:
> >>>So, I took the steps of forking Jude Nelson's vdev on git.devuan.org,
> >>>and augmenting it with an initial set up for deb package building.
> >>>
> >>>I set it up as three deb's:
> >>> libudev1-compat to replace libudev1,
> >>> vdevd being the daemon, and
> >>> vdev being the configuration, initramfs building and the set up as
> >>>sysvinit startup script.
> >>>
> >>>I've built sample packages for amd64, and tested on a pristine Devuan
> >>>1.0.0, (with DE+Xfce, printer server and ssh server). Available at
> >>>
> >>>https://git.devuan.org/ralph.ronnquist/vdev/release
> >>>
> >>>If you download those and install together (as in dpkg -i *.deb), your
> >>>system will change into using vdev rather than udev, but it doesn't
> >>>uninstall udev for you. It "only" removes udev's sysvinit scripts, and
> >>>udev's configuration for initramfs building, and the "init" script
> >>>(replaces the one from initramfs-tools).
> >>>
> >>>When installing, it might warn about volume symlinks not being
> >>>created. It's is safe to ignore this. Alternatively you install lvm2
> >>>first.
> >>>
> >>>You can also build your own deb's by cloning
> >>>https://git.devuan.org/ralph.ronnquist/vdev
> >>>
> >>>and using
> >>>$ make -f debian.mk
> >>>
> >>>provided you have dh_make and dpkg-buildpackage, as well as
> >>>build-essential. Since I'm quite new to package building, it only
> >>>contains the bare-bones so far. There are also no upstream changes to
> >>>source other than to Makefile's and initramfs scripts, with the
> >>>exception of the very minor patch to
> >>>vdevd/helpers/LINUX/udev-compat.sh.
> >>>
> >>>As a side note, eventually I realised that the main issue why the
> >>>keyboard didn't work, was that the evdev module didn't get installed,
> >>>and that it needs to be installed before /dev/input is populated.
> >>>
> >>>Ralph.
> >>
> >>Great work Ralph.
> >>
> >>I will test it during next week and give feedback.
> >>
> >>Since I had a go at making it work meself could you explain how
> >>you went about getting evdev module loaded before /dev/input was
> >>populated
> >>
> >>
> >>Also how did you solve the problem with logfile could not be written
> >>at the logfile path?
> >>
> >>Just curious and need to learn
> >>
> >>/scooby
> >
> >
> >Also Ralph may I ask if you believe the vdev upgrade would work on rpi3?
> >
> >rpi3 with really no peripherals as it is used as a server so it probably
> >would work
> >although I don't know how to install the build chain for it.
> >
> >Probably not a good idea to build vdev on the rpi3 when it is in
> >"production", right?
> >
> >/scooby
>
> 1) there's a "force_load evdev" early in the init-top script. Though
> possibly it rather should be deferred to the script that populates
> /dev/input.
>
> 2) The logfile is moved to /run/vdev/vdev.log
>
> 3) Off hand I would say it would work, but on the other hand, afaik vdev is
> still in beta state. And I don't know anything about rpi3. To try it out,
> you should first make sure you can revert easily. But I haven't thought too
> much about how to do that. In practice, vdev conflicts with udev, libudev1
> and initramfs-tools, because it removes or overwrites files (/links) from
> these.


It would be convenient from a user perspective, especaally while we
are still testingg, to be able to choose udev or vdev at boot time,
perhaps as a kerel parameter. But if the packages conflict to this
degree, I suppose there isn't much hope of it.

-- hendrik