I wished sys-fs/lvm2 would be split into devmapper and lvm Rationale: 1. Despite upstream also splits this two functionalities, see both NEWS: ftp://sources.redhat.com/pub/lvm2/WHATS_NEW_DM ftp://sources.redhat.com/pub/lvm2/WHATS_NEW 2. despite Lvm is badly supported with some actual setups, for example seperate_usr and systemd and genkernel 3. and trends eventually will go direction btrfs, which internally includes lvm features most systems depend on lvm2 due to cryptsetup and parted etc. This fat lvm2 ebuild is absolutely not self explaining its existence to the user until he looks deep into it. Also an installed Lvm2 produces confusing error messages when booting systemd. Allthough you can systemctl mask lvm ...
Then you should get it split at upstream, not here at downstream. But just that you know, device-mapper was a separate package before and LVM2 upstream merged them in purpose into same package. The build system is complex enough as is, even without carrying some custom splitting patch forever. As in, the benefits of splitting at downstream doesn't outweight the trouble, at all. Big -1 for splitting
Uuups, I thought upstream has split because of two different NEWS files ... Alternative: A USE flag disabling all of logical volume creation and systemd services Or: An eselect module to do just that. (as I know just config should not be done by USE flags anymore ...)
No, upstream MERGED device-mapper and lvm2 together, that's why there are two NEWS files. If you want it split again, take it up on their mailing list.
(In reply to Samuli Suominen from comment #1) > Then you should get it split at upstream, not here at downstream. ... > The build system is complex enough as is, even without carrying some custom > splitting patch forever. ... > Big -1 for splitting No, no spit is needed just a new _exclusive_ USE flag onlydm because source INSTALL file claims: If you only want the device-mapper libraries and tools use 'make device-mapper' or 'make install_device-mapper'. I tried locally emerge -B lvm2 with an manipulated src_compile src_compile() { pushd include >/dev/null emake popd >/dev/null emake AR="$(tc-getAR)" device-mapper emake CC="$(tc-getCC)" -C scripts } But it failed. Perhaps - support of reduced device-mapper make is buggy - Or I don't know how to restrict the emake function the correct way: ??? emake AR="$(tc-getAR)" device-mapper
Using "-C" also doesn't work: make -j2 AR=x86_64-pc-linux-gnu-ar -C device-mapper make: *** device-mapper: Datei oder Verzeichnis nicht gefunden. (not found)
It should work. If I issue in the source, which was previously configured by emerge: make device-mapper it shows an device-mapper restricted result: LVM2.2.02.99 # find . -name '*\.o' ./daemons/dmeventd/dmeventd.o ./daemons/dmeventd/libdevmapper-event.o ./libdm/libdm-string.o ./libdm/mm/pool.o ./libdm/mm/dbg_malloc.o ./libdm/libdm-deptree.o ./libdm/ioctl/libdm-iface.o ./libdm/regex/ttree.o ./libdm/regex/matcher.o ./libdm/regex/parse_rx.o ./libdm/libdm-report.o ./libdm/datastruct/list.o ./libdm/datastruct/bitset.o ./libdm/datastruct/hash.o ./libdm/libdm-config.o ./libdm/libdm-common.o ./libdm/libdm-file.o ./tools/dmsetup.o
What's the goal here? To save a couple of kb by not installing the LVM binaries? I read your rationale in comment #0 and that's about all I can glean from it. If you're really interested in this, I suggest you make an overlay and get that working there and use your own ebuild or use an INSTALL_MASK to save that space because this just isn't something we're going to support downstream.
@Doug Goldstein The formal answer is: The goal is user choice as ever. Gentoo should have at least the user choice Debian provides by providing this - called dmsetup there. My real answer: I was confused about having to have such a beast only to setup a LUKS encrypted home. The "beast" I don't care the size but the confusion. Do all of the new users have to read all of that creepy lvm man pages, really?
Created attachment 355374 [details] lvm2-2.02.99-r2.ebuild_with_onlydm_exclusive_use_flag This minimal _onlydm_ lvm2 provide dmsetup which is enough to LUKS encrypt /home dm_event is not needed to achieve this. Therefore it is possible to purge all of lvm but dmsetup.
-r2 Running here on linux-3.9.11 and systemd-206: Aug 08 04:58:21 maci systemd-cryptsetup[255]: Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/sda6. Aug 08 04:58:22 maci kernel: bio: create slab <bio-1> at 1 Aug 08 04:58:22 maci kernel: bio: create slab <bio-1> at 1 Aug 08 04:58:22 maci systemd[1]: Found device /dev/mapper/cr6. Aug 08 04:58:22 maci systemd[1]: Starting File System Check on /dev/mapper/cr6... Aug 08 04:58:22 maci systemd[1]: Started Cryptography Setup for cr6. Aug 08 04:58:22 maci systemd[1]: Starting Encrypted Volumes. Aug 08 04:58:22 maci systemd[1]: Reached target Encrypted Volumes. Aug 08 04:58:22 maci systemd-fsck[323]: hom: clean, 95250/4116400 files, 14312179/16449536 blocks Aug 08 04:58:22 maci systemd[1]: Started File System Check on /dev/mapper/cr6. Aug 08 04:58:22 maci systemd[1]: Mounting /home... Aug 08 04:58:23 maci systemd[1]: Mounted /home. Aug 08 04:58:23 maci kernel: EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: user_xattr Aug 08 04:58:23 maci systemd[1]: Starting Local File Systems. Aug 08 04:58:23 maci systemd[1]: Reached target Local File Systems.
Additional TODO is marked in my ebuild: Please help me to make this onlydm USE flag exclusive ... and my ebuild writing style of cause - it is my first.
Just for the record: The resultend bin package has 80% less in size.
Sounds like a lot of unnecessary work, now and in future, for no gain whatsoever. Plus bug 480232 looks like another attempt of reviving this same request. RESOLVED, WORKSFORME and mark bug 480232 as duplicate of this, imho
(In reply to Ulenrich from comment #8) > @Doug Goldstein > > The formal answer is: > The goal is user choice as ever. Gentoo should have at least the user choice > Debian provides by providing this - called dmsetup there. > > My real answer: > I was confused about having to have such a beast only to setup a LUKS > encrypted home. The "beast" I don't care the size but the confusion. Do all > of the new users have to read all of that creepy lvm man pages, really? You have a choice. Use INSTALL_MASK with this package. man make.conf
I have the choice to use my own ebuild, which I provided here. But why flooding the (ignorant) user with complicated and soonish or later outdated code (btrfs), which is essentially senseless for him, because lvm2 has its place in big data center but is overdrive for the desktop user.
in Comment #3 resolved - upstream problem me in comment #4 showed upstream has already solved the problem in comment #9 I provide the solution for downstream Gentoo @Doug, what is your problem with me (perhaps only my bad english grammar?)
(In reply to Ulenrich from comment #16) > in Comment #3 > resolved - upstream problem > > me in comment #4 showed > upstream has already solved the problem > > in comment #9 I provide the solution > for downstream Gentoo Effectively you're looking to split apart the package, which is not something that we want to support downstream. Which is why we've said take it upstream. > > @Doug, what is your problem with me > (perhaps only my bad english grammar?) I have no issue with you as a user or a developer. I have an issue with integrating this into our tree. That means that's another combination of options we need to support (we being Gentoo and the developers that maintain this package). That will fundamentally make our lives more difficult. In addition we now must update dependencies of all the packages that use lvm2 and any documentation that references lvm2. At the end of the day your goal is to save a some disk space from your installed media based on my understanding of your motivations so I'm explaining to you that Gentoo has already added this ability for users to make this happen and its called INSTALL_MASK.
@Doug >Effectively you're looking to split apart the package, which is not something >that we want to support downstream. Which is why we've said take it upstream. Upstream it is supported currently. If Ustream plans to depreciate this feature (make device-mapper) the next year and they discuss currently exatly that - then this bug simply invalidates. I don't think, because long time option RedHat is targeting are embedet little systems. They need to be thin. A thousend little gadget which produce netwise a kind of artificial intelligence. This is systemd with feature nspawn. Then comes Btrfs implementing nearly all of Lvm (without big data center). Considering the logic of package names from user perspective the best would be to split out "dmsetup" as Debian does. The easy solution is to just introduce a new USE flag "onlydm" and take my lvm2-2.02.99-r2.ebuild No patch no nothing but a new USE flag. Which can be droped if upstream depreciates the split make target feature.
I can confirm that we intend to continue supporting a separate device-mapper build upstream for people who only need libdevmapper +dmsetup (+dmeventd if configured). If we get reports of bugs in 'make device-mapper' then that is still something we will fix.
@Doug > In addition we now must update dependencies of all the packages that use lvm2 > and any documentation that references lvm2. If dmsetup is split out, two little steps are needed - dmsetup ebuild (just a few deletes) - in the cryptsetup ebuild as dependency lvm2||dmsetup > At the end of the day your goal is to save a some disk space No, No , No, I have told you some arguments already. Another is: I do some forum support some times a week. The User currently is - misleaded (directions will be btrfs not lvm) - confronted with strange lvm messages (One of this should be fixed recently) - sees lvm extra bloat falsely as a standard linux setup
@Doug >That will fundamentally make our lives more difficult. >In addition we now must update dependencies of all the packages >that use lvm2 and any documentation that references lvm2. No. A thin dmsetup just provided as a helper and blocking with lvm2 only needs updating cryptsetup documentation. Also following output shows the changes of the last year of DM are sparse regarding cryptsetup. The most are related to more complicated lvm setups and event messaging: /usr/share/doc/lvm/WHATS_NEW_DM shows --- Version 1.02.78 - 24th July 2013 Process thin messages once to active thin pool target for dm_tree. Optimize out setting the same value or read_ahead. Add DM_ARRAY_SIZE public macro. Move syslog code out of signal handle in dmeventd. Add DM_TO_STRING public macro. Always return success on dmeventd -V command call. Fix parsing of 64bit snapshot status in dmeventd snapshot plugin. Add dm_get_status_snapshot() for parsing snapshot status. Detecte mounted fs also via reading /proc/self/mountinfo. Add dm_mountinfo_read() for parsing /proc/self/mountinfo. Report error for nonexisting devices in dmeventd communication. Prevent double free error after dmeventd call of _fill_device_data(). Update dmevent structure message_data to simplify/fix error path handling. Validate passed params to dm_get_status_raid/thin/thin_pool(). Fix 'dmsetup splitname -o' to not fail if used without '-c' switch (1.02.6 Add dm_config_write_{node_out/one_node_out} for enhanced config output. Add dm_config_value_is_bool to check for boolean value in supported format Fix config node lookup inside empty sections to not return the section its Append discards and read-only fields to exported struct dm_status_thin_poo Fix segfault for truncated string token in config file after the first '"' Close open dmeventd FIFO file descriptors on exec (FD_CLOEXEC). Fix resource leak in error path of dmeventd's umount of thin volume. Automatically deactivate failed preloaded dm tree node. Add DM_DISABLE_UDEV environment variable to manage dev nodes by libdm only Fix dm_task_set_cookie to properly process udev flags if udev_sync disable Version 1.02.77 - 15th October 2012 ----
Regarding compatibility, our upstream policy is that if you update libdevmapper on a system to a newer release, existing already-compiled binaries are supposed to continue to work if they pick up the new library at runtime. As such, we do not change the .so version. But this is not guaranteed in the other direction - a program compiled against a particular release of libdevmapper is not guaranteed to work against an older release. (It might rely on new features not present in the old version.)
*** Bug 480232 has been marked as a duplicate of this bug. ***
USE=device-mapper-only is implemented in .105-r1. Please note this is added as an unsupported option. You keep the pieces when it breaks, bugs will be marked as invalid; I think you should be installing the full LVM.