I've been playing with this, and it's a bit complicated, but I wanted to track progress here and get your input on changes/design or find out if you're already working on this.
The first few obvious notes here: device-mapper is now included in lvm2. I'm guessing we just want to build it all as the same package vs. having two separate ones, and use a blocker. The only hangup to this is that lilo has a dep on device-mapper. The major patch for device-mapper and the major patch for lvm2 don't apply cleanly. The former is one I'm not familiar with, but the latter is just a config file change so it should be easy to sort out. The build itself fails when using "static". I'm building without for now, but will investigate how to sort that issue out too, if necessary.
Adding agk as the upstream maintainer.
Created attachment 185856 [details, diff] Patch for lvm2-2.02.45 compileage The current build of lvm2 doesn't work when you add the --static_link option, as there's a problem with dmeventd. It doesn't built the libdevmapper-event.a static library by default, which causes issues when linkage happens later. The attached patch fixes this.
Created attachment 185857 [details, diff] New config file patch New config file patch
Created attachment 185859 [details, diff] Replacement device-mapper-export patch The original patch from the device-mapper program mostly applies, this is just the cleanup of it for this package.
Created attachment 185860 [details] The ebuild itself The fixed up lvm2 ebuild. Note that this requires you have copied over the startup/stop and other scripts from the device-mapper ebuild directory as well, as it's now all encompassed in this single package.
To note, the necessity of the -dmeventd patch shows up on a new build. If you already have lvm2/device-mapper installed on the system, it won't manifest itself because it will link against the system libraries.
Seems to work nice here, just do not forget to add "|| die" to all newins and doins, as currently it does not fail if it fails to find the files you should copy in from device-mapper/files.
As a side note, lvm2 versions >=2.02.40 care about the underlying md device (software RAID), aligning physical extents to RAID chunks: this way filesystem parameters as XFS sunit and swidth can be really effective. People report huge benefits from proper alignment. It is possible to do it manually in versions <2.02.40 with --metadatasize pvcreate parameter, but few people care or know about it, and it's not so trivial which value to use. So please try to stabilize 2.02.45, or at least 2.02.42 that is already in the tree.
also maybe add --enable-pkgconfig Not much using it yet, but I do not think it hurts, and for us experimenting with devicekit-disks and similar it has its advantages.
I'm going to commit (with fixes noted) in the next few days unless anyone objects.
I was hoping that agk would chime in if it was a bad release to add, as he's told us to hold off before on certain LVM releases.
seems to be the version other distros are using, and it's playing with my XFS lvs nicely. Going to give it a shot, send flames my way. Committed.
By having an integrated device-mapper, this screws with cryptsetup and also evms -- thereby preventing one from having lvms2 installed in conjunction with the others.
Seemant, what's the fix?
For me the fix was to unmerge device-mapper and change the dependencies of those packages that like cryptsetup depends on device-mapper. || ( ( >=sys-fs/device-mapper-1.00.07-r1 ) ( >=sys-fs/lvm2-2.02.45 ) ) is what is in my cryptsetup ebuild in my overlay. I have yet to find a problem with that setup.
Caleb, You broke the tree. There are several items that still explicitly depend on device-mapper without having the following: || ( ( >=sys-fs/lvm2-2.02.45 ) ( >=sys-fs/device-mapper-1.00.07-r1 ) ) Additionally, the above the the proper way to do it to resolve issues going forward. I'm masking the new lvm2 until you can fix up the tree, Caleb.
All issues should be fixed. Leaving open for more feedback.
here, emerging lvm2-2.02.45 fails with the following errors: ln: creating symbolic link `./lvmcache.h': File exists ln: creating symbolic link `./errors.h': File exists /bin/sed -e "s/#VERSION#/2.02.45 (2009-03-03)/" lvm.8.in > lvm.8 ln: creating symbolic link `./toolcontext.h': File exists /bin/sed -e "s/#VERSION#/2.02.45 (2009-03-03)/" lvmchange.8.in > lvmchange.8 ln: creating symbolic link `./config.h': File exists ln: /bin/sed -e "s/#VERSION#/2.02.45 (2009-03-03)/" lvmdiskscan.8.in > lvmdiskscan.8 creating symbolic link `./defaults.h': File exists ln: creating symbolic link `./btree.h': File exists ln: /bin/sed -e "s/#VERSION#/2.02.45 (2009-03-03)/" lvmdump.8.in > lvmdump.8 creating symbolic link `./lvm-types.h': File exists ln: creating symbolic link `./str_list.h': File exists /bin/sed -e "s/#VERSION#/2.02.45 (2009-03-03)/" lvreduce.8.in > lvreduce.8 ln: creating symbolic link `./dev-cache.h': File exists ln: creating symbolic link `./device.h': File exists ln: creating symbolic link `./display.h': File exists ln: creating symbolic link `./filter-composite.h': File exists ln: creating symbolic link `./filter-md.h': File exists ln: creating symbolic link `./filter-persistent.h': File exists ln: creating symbolic link `./filter-regex.h': File exists ln: creating symbolic link `./filter-sysfs.h': File exists ln: creating symbolic link `./filter.h': File exists ln: creating symbolic link `./format1.h': File exists ln: creating symbolic link `./format_pool.h': File exists
(In reply to comment #19) > here, emerging lvm2-2.02.45 fails with the following errors: > fixed, by looking up the other bug report about .45 and temporarily setting MAKEOPTS="-j1" for the emerge. ;)
This is already in the tree and the makeopts stuff is resolved.
(In reply to comment #1) > The first few obvious notes here: > > device-mapper is now included in lvm2. I'm guessing we just want to build it > all as the same package vs. having two separate ones, and use a blocker. The > only hangup to this is that lilo has a dep on device-mapper. Parted is depends on device-mapper too.
