There's no issues, but due to the variable in the way Slackware packages things, I have to create directories in the temp install, then use cp to installing things which ends up being messy.

Not to complain, but the lack of a traditional configure file to set the install paths does make things more hectic, especially with some of the config files and other shell scripts.

While unnecessary, yet, it does make packing vdev a bit more hectic.

Slackware uses a sort of fakeroot style packager, pkgtools, that creates a temp directory for source and one for the build output. It then uses configure to create $DEST set paths for installing into the temp directory before packaging.

It's not anything major needed, but it would help in the future, especially installing to /lib64 for the lib path instead of /lib which is symlinked on other 64-bit distros.

Sent from my Windows Phone
________________________________
From: Jude Nelson<mailto:judecn@gmail.com>
Sent: ‎5/‎14/‎2015 12:33 AM
To: James Powell<mailto:james4591@hotmail.com>
Cc: dng@???<mailto:dng@lists.dyne.org>
Subject: Re: [Dng] [dng] vdev status update (2015-05-03)

Hi James,
On Thu, May 14, 2015 at 12:04 AM, James Powell <james4591@???>
wrote:

> Thanks Jude.
>
> The Slackware package is delayed, but only due to the lack of a Slackware
> style script. I might try to ask one of the Slackware team for assistance
> when I resume work. However, the package is fairly much completed in terms
> of installation points and directory setup.
>

Hey, that's pretty cool! First the AUR packages (from Jack Frost aka
openfbt), now Slackware.

I'm not a Slackware or Arch user, but please let me know if there's
anything I can do to make packaging easier? I don't want to make things
needlessly difficult :)

-Jude


> Sent from my Windows Phone
> ------------------------------
> From: Jude Nelson <judecn@???>
> Sent: 5/13/2015 8:24 PM
> To: dng@???
> Subject: [Dng] [dng] vdev status update (2015-05-03)
>
> Hey everyone,
>
> I have the latest news for vdev:
>
> * vdev now creates symlinks for:
> -- /dev/v4l/by-path
> -- /dev/disk/by-partuuid
> -- /dev/disk/by-partlabel
>
> Thank you Scooby for helping me confirm this!
>
> * vdev now sets the proper ownership and permissions for:
> -- /dev/mISDNtimer
> -- /dev/mwave
> -- /dev/parport[0-9]
> -- /dev/printer
> -- /dev/ppdev
> -- /dev/lp[0-9]
> -- /dev/irlpt[0-9]
> -- /dev/sch[0-9]
> -- /dev/pktcdvd[0-9]
> -- /dev/qft[0-9]
> -- /dev/zqft[0-9]
> -- /dev/nqft[0-9]
> -- /dev/nzqft[0-9]
> -- /dev/rawqft[0-9]
> -- /dev/nraqft[0-9]
> -- /dev/rawctl
> -- /dev/aoe
> -- /dev/lirc[0-9]
> -- /dev/legousbtower
> -- /dev/sonypi
> -- /dev/mmtimer
> -- /dev/sgi_*
> -- /dev/z90crypt
>
> * Didier Kryn has gotten vdevd and vdevfs to statically link and compile
> with musl libc. I'm looking forward to merging his contributions :)
>
> * the build system has been refactored to use Makefiles more
> appropriately:
> -- every generated file gets written to a separate build/ directory
> -- every generated file is created by a non-phony target (i.e. nothing
> happens by side-effect)
> -- global buildconf.mk for setting variables
> Thanks to Didier again for the suggestion!
>
> * the initramfs hook conditionally pulls in iproute2, lvm, dmsetup,
> blkid, etc. Moreover, vdev's helpers conditionally use these programs if
> they are present. This means that vdev doesn't strictly depend on them
> anymore, which is good if you're not using mapped devices or logical
> volumes. Thanks to Anto for the suggestion!
>
> * the initramfs hook pulls in the correct GNU libc files now, so chown(1)
> will work correctly in the initramfs. Thanks to Scooby, Isaac Dunham, Tom
> H for their help!
>
>
> [For Next Time]
>
> * The next immediate objective is to package vdevd for Devuan, to make
> it easier to test (in particular, easier to get a working initramfs). I'm
> currently dissecting udev's packaging and reading through Isaac's mdev
> scripts to see what to expect and what we can recycle. I've never packaged
> something this complex before. Thanks to Scooby, Anto, Tom H, and others
> for all their help on getting me this far!
>
> * Symlinks and permissions for RAID devices (/dev/md[0-9] and friends).
> I don't run a RAID myself, so I'll need to go set one up in QEMU. If
> someone wants to test vdev with a RAID, let me know, and I'll try to write
> a helper script to play around with sooner rather than later.
>
> * In some distros and configurations, a separate device manager (like
> mdev) can populate just enough of /dev to mount root, but not try to set up
> any symlinks. Vdevd must have a way for the admin to tell it to run helper
> scripts for the device even if its device node was already created
> (indicating that it has been set up), so the symlinks and permissions still
> get set appropriately. Thanks to Scooby for reporting this!
>
> Thanks,
> -Jude
>