Shared publicly  - 
 
As +Koen Kooi so aptly states, this is the perfect gift for a weekend's worth of entertainment.

It's sad to watch people delete code they don't understand.
 
Cute, gentoo wants to make a second, different fork of udev because the first gentoo fork is apparently too hostile to other gentoo developers.

Gentoo-devel and debian-devel, the gifts that keep on giving on rainy saturdays.
48
4
Valdis Kletnieks's profile photoLuca Barbato's profile photoRich Freeman's profile photoLennart Poettering's profile photo
58 comments
 
You must be referring to the systemd developers.
 
To be fair, some of that code not only needed deleting, it needed the authors to be slapped around with a large trout till they promised not to do stuff that misguided again.
 
+Luca Barbato I think Greg's done enough for Linux that he's allowed to mock others when they're in the process of doing something that's highly likely to make his job harder in the future.

And if you think Greg is mocking the systemd/udev developers, go track down what Linus had to say about the whole mess. (Hint - find out what happened to udev loading of firmware, and why).
 
I respect Greg's work on the kernel, but that still gives him no right to mock those who want to maintain a system according the philosophy which got Unix/Linux to the position it is currently enjoying in the first place.
 
Let's talk about the source of all this silliness in the first place, no? systemd + udev anyone? Yay for separation of layers, yay for modularity! ;-)
I'd suggest to also merge NetworkManager and why not, a system logger, a cron daemon and Gtk+ (you always need a GUI sooner or later...).
 
Hi Greg, just so you know that's not the reason why the second fork came to life, the real reason is mainly that we prefer to take a different approach towards our goals that will make adoption easier.
Similarly the code we are deleting because we "don't understand." is being deleted for quite a different reason since one of our goals is reducing the complexity of the fork by removing dependencies which aren't that necessary. Take into account that we only have one month to present a working solution and are working against the clock, thus reducing the codebase to the minimum possible is a reasonable first step.
For anything else you'd like to contructively criticize you are more than welcome to join us on #gentoo-udev in freenode.
 
By removing the kmod builtin, you add 100-150 entirely useless fork()/exec() to every bootup. But hey with it, we need only ~150 PIDs total to bring up an entire system, so who cares. :)

And I really love the commit log with:
"A ton of commits were made involving kmod and it is quite clear that it is broken, so we remove it.".

I'll get another beer from the fridge now ... :)
 
Yes and on a gentoo hardened (with the slowness of changing to kernel space created by the hardening) doing 150 execs of modprobe takes around 0.129 seconds on my core i5 not to mention most gentoo users not using intrds tend to build all or almost all of their modules inside the kernel.

We may get back to kmod later but for now we need to reduce udev to a working minimum, I hope you understand and can cope with us on that.
 
+Klondike klondikeño then why not just fork at a much older version of udev release?  Taking apart working code, only to add it back in at a later time, seems like more work than starting with older code and then later adding the same features back.

And 0.129 is a real amount of time, when my kernel can boot faster than that.  Remember, not all the world is an i5 processor, and some usage models have LAWS as to how fast a system has to boot in.

But hey, what do I know about udev, and this whole boot path and process :)
 
though I understand the reasons behind thinking a fork is a good plan, I don't know  why they don't just keep a set of patches in a git fork that they rebase for a while, until they get to a level where a real fork might be viable, these go crazy fork models, where they rename everything, change all the whitespace and fix Makefiles without doing anything useful don't generally end well.
 
Hi +Greg Kroah-Hartman about why don't just pick an older version this is mainly for political reasons from the guys from above (Council).

Well my kernel boots at around 5 seconds, so maybe I did something wrong... Take into account that even when loaded the modules still need to do stuff and access hardware, this tends to not to be particularly fast in my own experience. Also we don't plan to replace all udev installations (at least not yet) so please don't think of it as a replacement of udev for any cases, but mainly for those who have issues with the integration with systemd (the imposibility of having /usr on a separate partition is the one coming to my mind).

And well, you know I have had to review all the copyright notices in udev so according to that I can assume you know about udev :P

Dave the size of the changes makes it hard to just keep some patches which anyway will be rejected by upstream so we went for a whole fork. The project may or may not die but so far it has support from quite a few Gentoo devs and that's something.
 
+Klondike klondikeño it seems with git maintaining even major add on changes would be easier and put you in a better situation of why a fork is necessary. You can point at the rejected patches from upstream, and get a good story as to why the maintainers aren't useful.

Like I don't see upstream removing kmod support, so I've no idea why a fork would go crazy dropping chunks of code like that. Whereas patches to fix the /usr stuff might be fine, though the thing is the separate /usr argument is probably not a good a reason to fork, I'd guess not many people do that anyways, unless people suddenly decide to always have separate /usr because someone told them they couldn't.
 
+Dave Airlie The main problem comes with udev being merged with systemd which is what causes most of the issues in for example separate /usr. The problem is that the amount of changes such a patch would require would affect more than 50% of the code so not a single patch. Also an exaple of patches being rejected and causing this can be found at http://lists.freedesktop.org/archives/systemd-devel/2012-June/005435.html Also the issues caused by some recent changes (like the firmware ones) aren't helping the need not to keep a fork.

The reason why we dropped kmod is because we needed to reduce udev to a minimum we can build and test and improve on but which still can be used as drop-in replacement. Currently kmod on gentoo introduces dependencies on /usr which would bring back the issue. Of course we will try to get that fixed in the future, but please understand the fork has only lived for a week and we aren't magicians when it comes to code creation ;)
 
+Klondike klondikeño saying that the Gentoo council is dictating political reasons for which version of udev that you need to branch off of is very wrong.  Wrong if that really is true (which, after reading the minutes of the meeting I do not thing), and wrong if you think that is really the best way to go about doing this.

+Dave Airlie is trying to help you out here, ignoring his advice is pretty much certifying that this project isn't going to work out in the long run.  Sorry.
 
+Greg Kroah-Hartman That's what I inferred from ryao's explanation, may be wrong on that.

About +Dave Airlie's advice it's not much ignoring but not understanding his point I'm afraid.

WRT to the kmod stuff we intend to bring it back (as an optional dependency) before we release our first version and are working towards that.

Again guys thanks for your inputs, it is good to have people out of the ring telling you what you may be doing wrong :D
 
+Klondike klondikeño you do realize that you didn't really get rid of the kmod dependency by removing those changes, right?  The dependency is now just implicit instead of explicit. You "solved" nothing.

This has been an entertaining project to watch so far, cargo-cult coding at its finest.

Someone pass the popcorn, this is getting interesting.
 
I'm pondering doing a how to fork udev demostration by forking udev :-)
 
+Kay Sievers Really? Is there some PID shortage i don't know about? Should i put some in the freezer, just in case?
+Greg Kroah-Hartman Nice your kernel boots that fast. Would you LART some Chipset-designer/Firmware-Programmer at Intel/Gigabyte for me who set the SSS-Flag on my AHCI controller so SATA-ports can only be scanned serially which costs me 2.2 seconds?
 
+Greg Kroah-Hartman since I didn't do that particular change there is little I can realize but you can bring the issue back to ryao (who committed the changes) he goes by that monicker on freenode too.

+Dave Airlie feel free to do so I at least am open to learning
 
+Greg Kroah-Hartman so thinkpads also have no real motherboard? Know some place where i can get real motherboards for them?
 
+Klondike klondikeño I'd recommend doing something like openssh portable, treating the systemd/udev core as something that needs polishing, and basing a tree on top that you maintain the udev stuff separately. Really maintaining one rebaseable patche that rewrites the build system, although more annoying is rather less work that maintaining a complete udev fork.
Jiri H
 
+Jan Seiffert Based on what you mean a REAL motherboard. Imho motherboard for the original Thinkpads manufactured by IBM can be buyed in stores specialised for second-hand computer parts. The question for motherboard for the so-called Thinkpads manufactured by chinese Lenovo is a little bit ddiffficult, the Lenovo Thinkpads motherboards is from my point off view proprietary, i.e. every laptop is difficult, like laptops for example from Asus.
I can recommend laptops from System76 or ZaReason.
 
Greg, while in this case this may not apply, in general, I would disagree with your phrase "It's sad to watch people delete code they don't understand". For me, it's even more sad to watch people not delete code they don't understand or cannot maintain. They will break it anyway.

I, too, had a project that got forked due to my refusal to incorporate poorly-submitted changes needed for Windows compatibility. As the author of the fork uses only Windows, he unintentionally broke the autotools-based build system. Still, not only he did nothing after my request to fix it or delete it, he also didn't delete (obviously linux-specific) code related to ALSA from his Windows-only fork. That's what I call stupid.
 
+Dave Airlie You do realise that unmodified systemd upstream will build a udev version for you that works fine outside of systemd? It always has, and will continue to do so for a long time. So if you want to fork the thing to show the Gentoo folks how to properly fork, you can just clone our repo and that's it... No need to add or revert any patches to/of it.

The fork they did is mostly about disliking systemd, so they strip everything that carries the name of systemd, while being blind whether that technically makes any sense, and while trying hard avoid talking to systemd upstream about whether something makes sense or not, since systemd upstream is after all what they have their problems with.

I mean, they are welcome to fork as much as they want, it's Free Software at all. But "hate-driven" development (as +Greg Kroah-Hartman called it) is never good development, since it lacks the rationality that good code inherently requires.

Besides the implementation of the fork the point in time for the fork is questionnable as well. I mean, as we didn't actually break running standalone versions of udev, there's really no need to do anything now. They can fork it the minute where running a standalone udev is made impossible, and then it's super easy, it's just a git clone plus one revert. But for the long time until then it's really bogus continuously doing parallel maintenance of their own fork.

And regarding timeframes: Canonical's +Martin Pitt is actually a commiter on the systemd git tree.  He works on various things in the udev area. And since we value his work it would be stupid of us to break things for him anytime soon, so that Martin couldn't use systemd's udev anymore on Ubuntu.
 
Lennart, by making udev fail when /usr is not mounted you have made udev as an standalone project broken for many. Same applies to requiring systemd dependencies no matter what. I for once have no need of, for example, dbus on my servers since no package there uses it.
 
+Klondike klondikeño Dude, get your facts right.

udevd doesn't "fail" when /usr is not mounted. See http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken for details. systemd (not udevd!) will print a warning if you try to boot without /usr, but continue just fine afterwards. And it's really not udev that broke separate /usr, it's everything else in the stack. So, a) by just using udev, not systemd, you never see that warning, and b) systemd is merely the messenger, and just getting rid of that message doesn't fix anything. You need to fix every single component that assumes it can run from /usr in early boot. On that wiki page you will find an incomprehensive list of thise. Good luck with that.

And secondly, udevd built from the systemd tree does not need dbus. We carefully made sure that everyone of our binaries actually just links to the minimal library set it really needs. And for udevd dbus is not among it.

Really, dude, do your research first.
 
+Lennart Poettering didn't you refuse a patch to allow the tree to not build udev without systemd? introducing misc unneeded build deps for udev just because its bundled with systemd isn't exactly supporting people outside the little systemd is udev world. (though I don't see that as a valid reason for a full fork, since maintaining that one patch even if really really ugly with hostile upstream, is still less work than a full fork).
 
I can't read this any more, because I don't have popcorn.
 
+Kay Sievers Thanks for the Tip! But i guess the flag is set for a reason, or is it only so windows gets stable device ordering?
 
How dare someone spend their own time doing something I dislike!

If the fork has no merit, it will be abandoned.
 
+Greg Kroah-Hartman

And 0.129 is a real amount of time, when my kernel can boot faster than that.  Remember, not all the world is an i5 processor, and some usage models have LAWS as to how fast a system has to boot in.

That's nice for you, but how about people like me who get a hang on boot 50% of the time when udev is waiting for events? And no, this is not the firmware bug, this hang is FOREVER. And this is not a crazy setup, it's a normal Arch Linux setup, and the same happened in Fedora.

Do you really think 0.129 seconds for some machines is worth hanging FOREVER in others?

I want udev to boot no matter what, reliably, 100% of the time. Making the boot fast is nice, but not at the cost of potentially hanging, or failing.

I think udev+systemd developers have all their priorities wrong: reliability is more important than speed.

you do realize that you didn't really get rid of the kmod dependency by removing those changes, right?  The dependency is now just implicit instead of explicit. You "solved" nothing.

Are you aware that not everybody uses kmod? Some people work on embedded systems, and use busybox, which provides it's own minimalistic modprobe. Do these users don't count? I think it's very self-centered of you to dismiss others people's setups like that.

Take a look at buildroot's changes trying to keep up with all the dependencies of udev:

http://git.buildroot.net/buildroot/commit/?id=f94818b0fa77644b989bab5aa0866de7fe4ffbb1

Do you see how many dependencies were added? And that's just one release. Suddenly now I have to build a whole lot more stuff just to boot into a console shell in a beagleboard.

And I have to stumble upon issues such as udev silently depending on SOCK_CLOEXEC, which my embedded toolchain didn't have, and I had to find the hard way by realizing that 'udevadm control' didn't work, and bisect the issue. Nobody bothered to even check that at ./configure time.

You can attribute this to sloppiness, but that's the point; they make too many changes that are not backwards compatible, and where's the review? Many changes from Kay Sievers are a single line summary, no description, no reasoning, no explanation of the functional changes, no Reviewed-By, and hundreds of lines of change. I can point to many, many more examples if you are interested.

+Lennart Poettering

You do realise that unmodified systemd upstream will build a udev version for you that works fine outside of systemd? It always has, and will continue to do so for a long time. So if you want to fork the thing to show the Gentoo folks how to properly fork, you can just clone our repo and that's it... No need to add or revert any patches to/of it.

The key word here is for a long time. I'm not going to make any assumptions as to any possible hidden agendas, but there's a conflict what you said before:

http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html

Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.

FTR: Lennart has me blocked, so I had to go out of my way to figure out what he said, and he is probably not reading this.

+Dave Airlie

didn't you refuse a patch to allow the tree to not build udev without systemd? introducing misc unneeded build deps for udev just because its bundled with systemd isn't exactly supporting people outside the little systemd is udev world. (though I don't see that as a valid reason for a full fork, since maintaining that one patch even if really really ugly with hostile upstream, is still less work than a full fork).

Unfortunately it's way more than one patch. There's way too many things that are wrong with current udev, starting by the priorities.

Maybe you didn't read the mail from Linus Torvalds criticizing udev maintainership and calling for a fork:

http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49758/focus%3D1368822

but quite frankly, I am leery of the fact that the udev maintenance seems to have gone into some "crazy mode" where they have made changes that were known to be problematic, and are pure and utter stupidity.

There is a problem.

You can point at the rejected patches from upstream, and get a good story as to why the maintainers aren't useful.

It's already a good story:

http://www.h-online.com/open/news/item/Gentoo-developers-start-udev-fork-1752421.html

http://www.phoronix.com/scan.php?page=news_item&px=MTIzMDU

Like I don't see upstream removing kmod support, so I've no idea why a fork would go crazy dropping chunks of code like that.

The point is not to remove libkmod, The point is to make it optional. Some people might be using busybox's modprobe.

Do you seriously believe udev+systemd developers will accept a patch that will make libkmod optional? Wanna bet?

Personally I don't care about that, but I see why other people would.

The only thing I want is for udev to be reliable, and I just don't see that happening with the current udev maintainership.

these go crazy fork models, where they rename everything, change all the whitespace and fix Makefiles without doing anything useful don't generally end well.

It worked out just fine for X.org.

Seriously, I suggest you take a look at udev's code. I recommend you don't eat anything substantial before you do.
 
+Felipe Contreras it didn't work out for X.org like that at all.
I was trying to advise these guys on how to fork something properly, but they all sound a bit inexperienced. Its a lot more like Xouvert than X.org, I'm guessing nobody ever head of Xouvert.
 
+Dave Airlie Xouvert is more like the first fork of udev, X.org is more like the second fork. But that's besides the point. The point is that a fork is needed.
 
+Greg Kroah-Hartman

if you are using busybox, then please just use mdev, that is what it is there for, and why it was written.

So, you want to take away my freedom to decide what I want to use, and are going to assume you have all the facts of what my requirements are, and therefore your preference worths than mine? Don't you think that's a little patronizing?

Don't you think there's a remote possibility that I have a valid reason to prefer udev over mdev?

If you must know, the last time I tried mdev it was not loading all the modules properly. IIRC the module I was interested on had the appropriate "platform:" prefix, udev was loading it, but not mdev.

For more issues, you might find the notes in Gentoo's wiki interesting: http://wiki.gentoo.org/wiki/Mdev

Now, for the sake of argument can we suppose some people might have a valid reason to prefer udev over mdev? Then udev developers are breaking things for valid users willingly. Correct?

If I (or somebody else) provides a patch that makes udev work with or without libkmod, are you saying that such patch should be rejected? libkmod should be a hard dependency of udev, and the people that don't want it should suck it up, and the people that need something else should use mdev?

I don't see what the udev project could possibly gain by taking that stance.
 
+Kay Sievers

By removing the kmod builtin, you add 100-150 entirely useless fork()/exec() to every bootup. But hey with it, we need only ~150 PIDs total to bring up an entire system, so who cares. :)

I would rather have a version of udev that doesn't hang forever. Thank you.

And I really love the commit log with: "A ton of commits were made involving kmod and it is quite clear that it is broken, so we remove it.".

You must know a lot about all the setups of all Gentoo users to claim that kmod works properly in 100% of the setups and there isn't even a remote chance that it doesn't. Note: remember that Gentoo users can configure their systems any way they want. If not Gentoo, how about LFS users?
 
+Greg Kroah-Hartman

yes, we want to take away your "freedom". Keep this up and I'll ban you as well.

That's not really the heart of the problem, if you don't want to discuss the problems with libkmod, fine.

The real problems are the ones I mentioned above, like the fact that udev hangs forever 50% of the time on some setups. Why aren't you commenting on those?

You don't see hanging forever as a problem? You think the lack of reviews, and proper commit messages is acceptable? You think the firmware issue that was triggered willingly by the developers, and prompted Linus to call them crazy, is OK?

Those are the important questions.

Anyway, regarding libkmod, you are evading the question; are you in favor of udev rejecting a patch that allows both working with libkmod, and modprobe?

If you are in favor, then you are with the eudev side.

If you say I should use mdev, you are hinting that you are not in favor of such a patch, and that takes away my freedom to choose the solution I want: udev. It's very simple: given my requirements, are you going to let me use udev or not?

I think (and hope), that you are in favor of such a patch, so I think (and hope) you don't want to take away anybody's freedom, but I'm asking because it's not clear why you said I should use mdev, and not udev.

It's a simple question. Yes, or No? If you want to block me for asking a simple question, go ahead, the but the users that want to build without libkmod are still there. And BTW. The reasons for Gentoo users to avoid libkmod are entirely different.
 
+Felipe Contreras did you file a bug report for the delay problem?

And it's up to the maintainers if they want to take such a patch. I know I sure would not as that defeats the purpose of the kmod work, which was done for a reason, to solve a real problem. 
 
Also, if you disagree with the current developers about decisions like this, then fork. And be prepared to handle the fallout. No developer owes you anything, nor are they taking anything away from you.
 
+Greg Kroah-Hartman

did you file a bug report for the delay problem?

What would be the point? To let it rot in their bugzilla?

Edit: And it's not a delay, it's hang... forever. I thought I made that clear.

Take a look at this one, which is also a hang (forever):
https://bugs.freedesktop.org/show_bug.cgi?id=53406

The guy provided a reliable test-case, bisected the offending commit, reverted it on the latest git to make sure it fixed the problem.

And it has been gathering dust since August.

But if you want me to do that, I can certainly do it, it would just be ignored. And even if they manage to fix it, that won't change the fact that their development practices are bad, and they will keep introducing these kinds of bugs. Would it?

As a maintainer, would you ever accept a patch like this?

commit 3cf5266b029c1ec4522edc6b42d874d80407a246
Author: Kay Sievers <kay.sievers@vrfy.org>
Date:   Tue Dec 27 17:02:52 2011 +0100

    builtin: move usb-db, pci-db to builtins

 Makefile.am                            |  26 +++-------
 configure.ac                           |  78 +++++++++++++---------------
 extras/usb-db/.gitignore               |   2 -
 extras/usb-db/usb-db.c                 | 264 ---------------------------------------------------------------------------------------------
 rules/rules.d/75-net-description.rules |   4 +-
 rules/rules.d/75-tty-description.rules |   4 +-
 rules/rules.d/78-sound-card.rules      |   4 +-
 udev/udev-builtin-hwdb.c               | 252 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 udev/udev-builtin.c                    |   2 +
 udev/udev.h                            |   4 ++
 10 files changed, 305 insertions(+), 335 deletions(-)

http://cgit.freedesktop.org/systemd/systemd/commit/?id=3cf5266b029c1ec4522edc6b42d874d80407a246

With no description, no review, no explanation of what things might be broken, what might fixed, what's the purpose... Nothing.

Of course not! If you accept patches like that you will introduce regressions very easily. Right?

And that's exactly what happens in udev all the time.

And it's up to the maintainers if they want to take such a patch.

That's right, and what do you do when the maintainers keep rejecting perfectly reasonable patches, and don't listen to criticism? That's right; you fork.

I know I sure would not as that defeats the purpose of the kmod work, which was done for a reason, to solve a real problem.

And it will solve a problem, for the people that have libkmod installed. Would it not?

libkmod would be optional so we have both benefits; forks are avoided for the people that have libkmod, and modprobe fallback is used for the ones that don't. Absolutely nothing would change for the people like you, that have libkmod installed.

So, there's the need for a fork right there; because certain users are being marginalized.

Also, if you disagree with the current developers about decisions like this, then fork.

Isn't that what we are doing?
 
+Greg Kroah-Hartman

Actually, this is the one that I was aiming for:

commit 796b06c21b62d13c9021e2fbd9c58a5c6edb2764
Author: Kay Sievers <kay@vrfy.org>
Date:   Mon Oct 22 18:23:08 2012 +0200

    udev: add hardware database support

 Makefile.am                     |    18 +-
 TODO                            |     1 +
 configure.ac                    |    29 -
 hwdb/.gitignore                 |     2 +
 hwdb/20-pci-vendor-product.hwdb | 63420 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hwdb/20-usb-vendor-product.hwdb | 47304 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hwdb/ids-update.pl              |    80 +
 rules/50-udev-default.rules     |     2 +-
 rules/75-net-description.rules  |     4 +-
 rules/75-tty-description.rules  |     4 +-
 rules/78-sound-card.rules       |     5 +-
 src/tmpfiles/tmpfiles.c         |     5 +-
 src/udev/udev-builtin-hwdb.c    |   476 +-
 src/udev/udev-builtin.c         |     5 +-
 src/udev/udev-hwdb.h            |    69 +
 src/udev/udev.h                 |     7 +-
 src/udev/udevadm-hwdb.c         |   548 +
 src/udev/udevadm.c              |     3 +-
 18 files changed, 111757 insertions(+), 225 deletions(-)

http://cgit.freedesktop.org/systemd/systemd/commit/?id=796b06c21b62d13c9021e2fbd9c58a5c6edb2764
 
+Felipe Contreras That really is a crazy commit. I don't think any sane maintainer would accept this anywhere. Especially as there are many unrelated changes in it.
 
+Tom Gundersen Geez, I wonder where you got the idea from.

Except there's a little problem; you break the systems when you --disable-kmod and --disable-blkid. All you do is disable the rules that used them, so essentially you break the original functionality.

So many complains about gudev developers not knowing that they do, because removing those dependencies adds a few miliseconds, and yet you, official udev developers, go ahead and break the functionality completely.

If you need guidance on how to implement it properly, without breaking functionality, check eudev's patches (WIP):

https://github.com/gentoo/eudev/commit/626bf3de512f8694ecebcfc0e16f1ea6ec9f1ec3
 
+Lennart Poettering

yes, we didn't add configure switches to build arbitrary specific binaries from the tree only and leave others out, since make already has a way to do that, by running "make udevd" or suchlike.

Ah, so I just have to do:

make libudev.la
make systemd-udevd
make udevadm
make accelerometer
make scsi_id
make ata_id
make cdrom_id
make v4l_id
make mtd_probe
make collect
make src/udev/udev.pc
make src/libudev/libudev.pc

Great, I have udev built. Now what?

Do do 'install -m 755 ./.libs/libudev.so $prefix/libudev.so.1.1.6' manually? Or do I do 'make install-libLTLIBRARIES', nah, that installs a lot of irrelevant stuff. 'make install-libLTLIBRARIES lib_LTLIBRARIES=libudev.la' seems to do the trick. Next is 'install-rootlibexecPROGRAMS', but that is plugging some stuff from other targets, so I have to specify lib_LTLIBRARIES again.

In the end, I have to do something like this:

export lib_LTLIBRARIES=libudev.la \
rootlibexec_PROGRAMS=systemd-udevd \
bin_PROGRAMS=udevadm \
am__EXEEXT_23= \
pkgconfiglib_DATA=src/libudev/libudev.pc

make -e install-libLTLIBRARIES \
install-rootlibexecPROGRAMS \
install-binPROGRAMS \
install-udevlibexecPROGRAMS \
install-sharepkgconfigDATA \
install-pkgconfiglibDATA \
install-dist_udevrulesDATA

Wow! so easy?!

_We even documented that:
http://wiki.freedesktop.org/wiki/Software/systemd/MinimalBuilds_

That says 'make foobar' it doesn't specify how to install foobar. And no, building everything is not an option.

It's no wonder some people have opted to write their own Makefiles instead:

http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html

I think that's what I'm going to do.
 
+Felipe Contreras the use case I describe in the commit was suggested in the original Gentoo discussion. I thought it made sense.

I don't think using an alternative modprobe is something upstream should support explicitly. However, it is now trivial: disable kmod and provide your own version of the udev rules file, calling modprobe directly instead of using the builtin.

As to installing only udev from the upstream sources: write your own Makefile or do what you wrote, either way it is a trivial amount of work, and makes one wonder about the need for forking the whole repository.
 
+Tom Gundersen

I don't think using an alternative modprobe is something upstream should support explicitly.

So you think it's better to do nothing, load nothing, and break things?

However, it is now trivial: disable kmod and provide your own version of the udev rules file, calling modprobe directly instead of using the builtin.

It is more trivial to just do --disable-kmod on eudev and be done with it.

As to installing only udev from the upstream sources: write your own Makefile or do what you wrote, either way it is a trivial amount of work

I already wrote my own Makefile, but it was certainly not trivial, and it still needs work. But I would use it to make it easier for forks to work together, not prevent them.

A successful fork is still very much needed.
 
I can't say I have any major complaints with mainline udev or plans to switch away from it.  In fact, I've entertained switching to systemd on my Gentoo boxes.

However, it seems a bit much to sit back and critique every commit in a project that is all of two days old.  If I hire somebody to remodel my kitchen I'm not going to sit there and complain about the order he rips out my old cabinets in.  If somebody sees a mistake by all means point it out in a constructive way, but it really bothers me when I see people in the FOSS community basically insulting each other.  The people behind the fork are all udev outsiders, so they're going to make mistakes until they learn the ropes.  

If it were me I'd take time to learn more about udev before forking it, which is part of why I migrated to an initramfs months ago and decided that I like it.  

And if the udev team is right that the way they're doing things is obviously the right way, then they need not fear.  If that is so, then the result of this is a bunch of udev outsiders set out to fork udev, but as they confront the challenges the insiders have dealt with, they'll come to similar confusions.  Then the FOSS world ends up with more potential udev contributors.  I'll take people writing code over people complaining about people writing code any day...  :)
Add a comment...