Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Tue, Jun 19, 2012 at 06:44:25PM +0200, Michael Olbrich wrote: This is not about the files from systemd. It's about the dependencies. Every user of a source based distro, that only wants systemd now has to first install dbus then udev, and then remove dbus again. Shouldn't the build system do this automatically? I can understand it is inconvenient and makes things slower, but if you're building from source anyway, a few build time dependencies is ok? Trying to see this in relation to jhbuild. There I hate webkit and mozilla, but those are in a different order than what is discussed here. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Wed, Jun 20, 2012 at 09:38:22AM +0200, Olav Vitters wrote: On Tue, Jun 19, 2012 at 06:44:25PM +0200, Michael Olbrich wrote: This is not about the files from systemd. It's about the dependencies. Every user of a source based distro, that only wants systemd now has to first install dbus then udev, and then remove dbus again. Shouldn't the build system do this automatically? Why should it? The equivalent for a normal distro would be to require e.g. perl in udev for a post-install script only. And then you expect the package manager to understand this and install perl before installing udev and remove it again afterwards. I can understand it is inconvenient and makes things slower, but if you're building from source anyway, a few build time dependencies is ok? While I try to keep the dependencies at a minimum, this is not the real issue. I don't think you understand the embedded use-case. Right now what we have is basically a set of rules (how to build things) and some configuration (what to build). And with one command we get a root filesystem image. The configuration is more or less a list of packages to build. Now I need two lists, what to build and what to include in the final image. And while it is possible to implement this, it's also a lot more complex than fixing the real issue for udev. Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Wed, Jun 20, 2012 at 01:46:40PM +0200, Olav Vitters wrote: On Wed, Jun 20, 2012 at 01:32:52PM +0200, Michael Olbrich wrote: On Wed, Jun 20, 2012 at 09:38:22AM +0200, Olav Vitters wrote: On Tue, Jun 19, 2012 at 06:44:25PM +0200, Michael Olbrich wrote: This is not about the files from systemd. It's about the dependencies. Every user of a source based distro, that only wants systemd now has to first install dbus then udev, and then remove dbus again. Shouldn't the build system do this automatically? Why should it? The equivalent for a normal distro would be to require e.g. perl in udev for a post-install script only. And then you expect the package manager to understand this and install perl before installing udev and remove it again afterwards. Not really. There are build time dependencies and runtime dependencies. Build time stuff is only of a concern of building the software. Has no relevance to post-install scripts (talking about post-install rpm scripts, not sure if you mean the same). Yes really. This is about the end user of the distro. Which means comparing installing packages. I can understand it is inconvenient and makes things slower, but if you're building from source anyway, a few build time dependencies is ok? While I try to keep the dependencies at a minimum, this is not the real issue. I don't think you understand the embedded use-case. Right now what we have is basically a set of rules (how to build things) and some configuration (what to build). And with one command we get a root filesystem image. The configuration is more or less a list of packages to build. Now I need two lists, what to build and what to include in the final image. And while it is possible to implement this, it's also a lot more complex than fixing the real issue for udev. This is part of the build systems for the distributions that I know (rpm based; opensuse, fedora, rhel, mageia, mandriva). Forgot how apt does it, assume it has the same functionality. What I mean that you have Requires: and BuildRequires:. What you need for building is not what dependencies are needed once it has been built. It sometimes happens that to apply a patch you need additional BuildRequires to e.g. regenerate 'configure' and so on. That won't result in any extra runtime dependencies. We all know this works very well with the big binary distros. This whole thread is about source distros. Which means every user has to support all build time requirements. Which means they are all part of the final system of _every_ user unless we add extra complexity to keep unwanted things out. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
2012/6/19 Kay Sievers k...@vrfy.org On Tue, Jun 19, 2012 at 1:10 PM, Michael Olbrich m.olbr...@pengutronix.de wrote: On Tue, Jun 19, 2012 at 11:21:58AM +0200, Lennart Poettering wrote: On Fri, 15.06.12 20:06, Bryan Kadzban (br...@kadzban.is-a-geek.net) wrote: dbus libcap I am quite happy with depending on these two as it makes little sense to build an OS without it, unless you go super minimal in which case sysemd/udev are not relevant. For embedded distros udev without systemd is a very real usecase. m4 intltool gperf (--enable-keymap will require gperf for a udev build as well) These are only build-time deps, and hence are totally OK to have. I don't care about these. But cross-compiling dbus when it's not actually wanted or needed is not ok. There are zero known problems with doing that with D-Bus. All you do is waste CPU cycles on the build system, which is what we all do anyway when we do your own stuff and don't use a pre-compiled package from a distro. I really don't see a problem here besides some inconvenience, which is justified at this moment, where everything is just newly introduced stuff. I mean, the next thing you come up with is a patch to not require automake and use only make, just because you have a problem with dependencies? I mean, seriously. This is uncalled for. Depending on a good build-system is ok. But it was clearly stated that using udev without systemd will still be possible. I don't see why it should not be possible to build udev without systemd and therefore any extra dependencies. We said udev *runs* alone, not that you can tweak the build system to only build it. And that is still all true. Without patching the build sys, you can *probably* temporarily work around the build dependencies with things like: $ export PKG_CONFIG_PATH=$PWD; \ echo -e Name: dbus-1\nDescription: stub\nVersion: 999 dbus-1.pc $ ./configure $ make systemd-udevd udevadm ata_id Longer-term plan is to move the D-Bus daemon functionality to the kernel, and let systemd talk directly to the kernel. The external D-Bus dependency might go entirely away with that. At that point, when there is no D-Bus daemon runtime dependency anymore, it is very likely that udevd/udevadm/libudev will use the kernel's D-Bus interfaces too instead of the home-grown IPC, and all of that build-sys splitting and fiddling makes not much sense anymore. NOKIA married with M$ , so, this kdbus stuff is vanished, said. So, please keep that build-sys stuff local please and do not expect any of this to be merged upstream at this moment. We can merge reasonable and obvious patches to make things easier, like we removed the needless D-Bus tools linking for the udev binaries, but we do not want to make promises about full modularization, or things like disabling the build of systemd in the systemd tarball. We properly support *running* (and distros can do such packaging) a standalone udev, for people who run systems without systemd. We just do not support fully separated standalone *builds* at the moment, and maybe we never will. If things turn out differently in the future as we expect them to be, we can discuss that again, but that is unlikely to happen before the end of the year. We first need to see where we will end up with D-Bus when we get there, it might change all the assumptions people make about this sort dependency so far. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Wed, Jun 20, 2012 at 02:34:52PM +0200, Michael Olbrich wrote: On Wed, Jun 20, 2012 at 01:46:40PM +0200, Olav Vitters wrote: On Wed, Jun 20, 2012 at 01:32:52PM +0200, Michael Olbrich wrote: On Wed, Jun 20, 2012 at 09:38:22AM +0200, Olav Vitters wrote: Shouldn't the build system do this automatically? Why should it? The equivalent for a normal distro would be to require e.g. perl in udev for a post-install script only. And then you expect the package manager to understand this and install perl before installing udev and remove it again afterwards. Not really. There are build time dependencies and runtime dependencies. Build time stuff is only of a concern of building the software. Has no relevance to post-install scripts (talking about post-install rpm scripts, not sure if you mean the same). Yes really. This is about the end user of the distro. Which means comparing installing packages. It is only needed during the build, so don't see what you're getting at. Install when needed, remove after. [..] It sometimes happens that to apply a patch you need additional BuildRequires to e.g. regenerate 'configure' and so on. That won't result in any extra runtime dependencies. We all know this works very well with the big binary distros. This whole thread is about source distros. Which means every user has to support all build time requirements. Which means they are all part of the final system of _every_ user unless we add extra complexity to keep unwanted things out. I don't see why it should. Just install the build time dependencies automatically and remove afterwards. If the build system of a source based distribution doesn't know the difference between these, then seems the build system needs to be taught the difference. IMO, this seems to be just a difference in perception. IMO there is a difference between build time and runtime dependencies. If you think that there is no difference (or should be no difference), then every extra build time dependency causes pollution (cause the build stuff is kept on machines instead of removed after building). I don't see why there is a difference between building at a build machine or building at users machine should make any difference. On both types, you don't want to keep those build dependencies on the machine. I can see you of course need to build all the various build time dependencies, so if there a lot it'll result in wasted CPU cycles... but if you want efficiency on that it is easier to have something build everything for you. In any case, if there is no knowledge of build vs runtime dependencies, a machine will already have loads of packages purely for making stuff build. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Wed, Jun 20, 2012 at 09:40:39PM +0200, Robert Schwebel wrote: Currently, the workflow would be like this: 1) build other components 2a) build prerequisites necessary for systemd, which are otherwhise unneeded; this needs to be installed into the local sysroot in order to let systemd pick up the prerequisites 2b) build systemd+udev 2c) somehow remove the wrong components from sysroot again, as all the rest of the system is not allowed to see them (otherwhise their configure scripts would assume the features to be there) 2d) install only udev 3) move on Instead of: 1) build other components 2) configure with just the right switches, make 3) move on In ptxdist, we have 700+ packages which don't need this kind of special handling (especially 2c will really be a pain). And all this because of something which can be solved in configure.ac. Note: This discussion shouldn't be about if source distributions are a valid use case. Fact is that there are source distributions and people have their reasons to use them. And all source distributions have this issue. We should avoid that everyone implements his own uggly workaround. Agreed. As shown in this thread, there are definitely enough use cases out there for building stand-alone udev that this should be handled upstream so that everyone doesn't have to invent a workaround. Like I've said multiple times on this thread, I don't care whether or not *my* patches get used, but it would be greatly appreciated if there was a way to build udev standalone. Thanks for your consideration, William pgpcmny1kQMIK.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Wed, Jun 20, 2012 at 01:46:41PM -0700, Kok, Auke-jan H wrote: You could easily build dbus-for-systemd inside the systemd buildroot, and never install dbus to the sysroot, but in a temporary location. After building the local dbus, system and udev, you just make install in only the udev parts and you now have a system without dbus or systemd. We always find ways to work around crude upstream makefiles, that's not the point. Most of the code in ptxdist/oe/buildroot/... is about patching upstream packages for proper cross compilation. Most of that is necessary because people invent their own superduper makefiles, instead of using proven technologies like autotools etc. The arguments are all in Lennart's paper about userspace for kernel hackers, and we fully second that. The thing is that the source distro maintainers need to invent their own workarounds, in different ways and with different bugs. So our suggestion is to go the systemd way and provide one proven solution in the upstream. However, all this is theory without patches. So I'd suggest that we do our homework first and check if we find a minimal patch which avoids complexity for the maintainers. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Thu, 14.06.12 21:32, William Hubbs (w.d.hu...@gmail.com) wrote: Yes, we could, but what about exherbo, funtoo, linux from scratch and the other source based distros that may be out there? I fail to see what this has to do with source-based distros. They can just build systemd as normal and drop everything they don't want. Where's the difference to an RPM-based distro there? Whether the build happens locally or on some build server should have no influence on the build system. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Tue, Jun 19, 2012 at 11:21:58AM +0200, Lennart Poettering wrote: On Fri, 15.06.12 20:06, Bryan Kadzban (br...@kadzban.is-a-geek.net) wrote: dbus libcap I am quite happy with depending on these two as it makes little sense to build an OS without it, unless you go super minimal in which case sysemd/udev are not relevant. For embedded distros udev without systemd is a very real usecase. m4 intltool gperf (--enable-keymap will require gperf for a udev build as well) These are only build-time deps, and hence are totally OK to have. I don't care about these. But cross-compiling dbus when it's not actually wanted or needed is not ok. I mean, the next thing you come up with is a patch to not require automake and use only make, just because you have a problem with dependencies? I mean, seriously. This is uncalled for. Depending on a good build-system is ok. But it was clearly stated that using udev without systemd will still be possible. I don't see why it should not be possible to build udev without systemd and therefore any extra dependencies. Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Tue, Jun 19, 2012 at 1:10 PM, Michael Olbrich m.olbr...@pengutronix.de wrote: On Tue, Jun 19, 2012 at 11:21:58AM +0200, Lennart Poettering wrote: On Fri, 15.06.12 20:06, Bryan Kadzban (br...@kadzban.is-a-geek.net) wrote: dbus libcap I am quite happy with depending on these two as it makes little sense to build an OS without it, unless you go super minimal in which case sysemd/udev are not relevant. For embedded distros udev without systemd is a very real usecase. m4 intltool gperf (--enable-keymap will require gperf for a udev build as well) These are only build-time deps, and hence are totally OK to have. I don't care about these. But cross-compiling dbus when it's not actually wanted or needed is not ok. There are zero known problems with doing that with D-Bus. All you do is waste CPU cycles on the build system, which is what we all do anyway when we do your own stuff and don't use a pre-compiled package from a distro. I really don't see a problem here besides some inconvenience, which is justified at this moment, where everything is just newly introduced stuff. I mean, the next thing you come up with is a patch to not require automake and use only make, just because you have a problem with dependencies? I mean, seriously. This is uncalled for. Depending on a good build-system is ok. But it was clearly stated that using udev without systemd will still be possible. I don't see why it should not be possible to build udev without systemd and therefore any extra dependencies. We said udev *runs* alone, not that you can tweak the build system to only build it. And that is still all true. Without patching the build sys, you can *probably* temporarily work around the build dependencies with things like: $ export PKG_CONFIG_PATH=$PWD; \ echo -e Name: dbus-1\nDescription: stub\nVersion: 999 dbus-1.pc $ ./configure $ make systemd-udevd udevadm ata_id Longer-term plan is to move the D-Bus daemon functionality to the kernel, and let systemd talk directly to the kernel. The external D-Bus dependency might go entirely away with that. At that point, when there is no D-Bus daemon runtime dependency anymore, it is very likely that udevd/udevadm/libudev will use the kernel's D-Bus interfaces too instead of the home-grown IPC, and all of that build-sys splitting and fiddling makes not much sense anymore. So, please keep that build-sys stuff local please and do not expect any of this to be merged upstream at this moment. We can merge reasonable and obvious patches to make things easier, like we removed the needless D-Bus tools linking for the udev binaries, but we do not want to make promises about full modularization, or things like disabling the build of systemd in the systemd tarball. We properly support *running* (and distros can do such packaging) a standalone udev, for people who run systems without systemd. We just do not support fully separated standalone *builds* at the moment, and maybe we never will. If things turn out differently in the future as we expect them to be, we can discuss that again, but that is unlikely to happen before the end of the year. We first need to see where we will end up with D-Bus when we get there, it might change all the assumptions people make about this sort dependency so far. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Tue, Jun 19, 2012 at 01:59:14PM +0200, Kay Sievers wrote: On Tue, Jun 19, 2012 at 1:10 PM, Michael Olbrich m.olbr...@pengutronix.de wrote: On Tue, Jun 19, 2012 at 11:21:58AM +0200, Lennart Poettering wrote: On Fri, 15.06.12 20:06, Bryan Kadzban (br...@kadzban.is-a-geek.net) wrote: dbus libcap I am quite happy with depending on these two as it makes little sense to build an OS without it, unless you go super minimal in which case sysemd/udev are not relevant. For embedded distros udev without systemd is a very real usecase. m4 intltool gperf (--enable-keymap will require gperf for a udev build as well) These are only build-time deps, and hence are totally OK to have. I don't care about these. But cross-compiling dbus when it's not actually wanted or needed is not ok. There are zero known problems with doing that with D-Bus. All you do is waste CPU cycles on the build system, which is what we all do anyway when we do your own stuff and don't use a pre-compiled package from a distro. I really don't see a problem here besides some inconvenience, which is justified at this moment, where everything is just newly introduced stuff. Well, source based distros typically try not to waste CPU cycles, because at some point it just takes too long. Also, while I can skip installing the systemd specific stuff, dbus libcap and expat are already there. But more importantly I'm afraid that if we don't raise our concerns now, that at some point glib isn't optional any more, for reasons much like those stated in this thread. I mean, the next thing you come up with is a patch to not require automake and use only make, just because you have a problem with dependencies? I mean, seriously. This is uncalled for. Depending on a good build-system is ok. But it was clearly stated that using udev without systemd will still be possible. I don't see why it should not be possible to build udev without systemd and therefore any extra dependencies. We said udev *runs* alone, not that you can tweak the build system to only build it. And that is still all true. Without patching the build sys, you can *probably* temporarily work around the build dependencies with things like: $ export PKG_CONFIG_PATH=$PWD; \ echo -e Name: dbus-1\nDescription: stub\nVersion: 999 dbus-1.pc $ ./configure $ make systemd-udevd udevadm ata_id Longer-term plan is to move the D-Bus daemon functionality to the kernel, and let systemd talk directly to the kernel. The external D-Bus dependency might go entirely away with that. At that point, when there is no D-Bus daemon runtime dependency anymore, it is very likely that udevd/udevadm/libudev will use the kernel's D-Bus interfaces too instead of the home-grown IPC, and all of that build-sys splitting and fiddling makes not much sense anymore. That would just make D-Bus a requirement for udev too. After all the D-Bus dependency is for libdbus and not the daemon. So, please keep that build-sys stuff local please and do not expect any of this to be merged upstream at this moment. We can merge reasonable and obvious patches to make things easier, like we removed the needless D-Bus tools linking for the udev binaries, but we do not want to make promises about full modularization, or things like disabling the build of systemd in the systemd tarball. Well I think that such a modularization should be the byproduct of a clean design and architecture, but I guess that's a matter of opinion. Does this mean that if I sent a patch that reorders things in configure.ac, so that I only need to add one 'if ENABLE_SYSTEMD' afterwards, it has a good chance that it's applied? We properly support *running* (and distros can do such packaging) a Now it's properly. Can we please get a clear answer here? standalone udev, for people who run systems without systemd. We just do not support fully separated standalone *builds* at the moment, and maybe we never will. If things turn out differently in the future as we expect them to be, we can discuss that again, but that is unlikely to happen before the end of the year. We first need to see where we will end up with D-Bus when we get there, it might change all the assumptions people make about this sort dependency so far. Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Tue, Jun 19, 2012 at 11:13:50AM +0200, Lennart Poettering wrote: On Thu, 14.06.12 21:32, William Hubbs (w.d.hu...@gmail.com) wrote: Yes, we could, but what about exherbo, funtoo, linux from scratch and the other source based distros that may be out there? I fail to see what this has to do with source-based distros. They can just build systemd as normal and drop everything they don't want. Where's the difference to an RPM-based distro there? Whether the build happens locally or on some build server should have no influence on the build system. This is not about the files from systemd. It's about the dependencies. Every user of a source based distro, that only wants systemd now has to first install dbus then udev, and then remove dbus again. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Tue, 19.06.12 18:44, Michael Olbrich (m.olbr...@pengutronix.de) wrote: Yes, we could, but what about exherbo, funtoo, linux from scratch and the other source based distros that may be out there? I fail to see what this has to do with source-based distros. They can just build systemd as normal and drop everything they don't want. Where's the difference to an RPM-based distro there? Whether the build happens locally or on some build server should have no influence on the build system. This is not about the files from systemd. It's about the dependencies. Every user of a source based distro, that only wants systemd now has to first install dbus then udev, and then remove dbus again. I think the way to get rid of this dep is by moving D-Bus into the kernel. WHich is something folks at Collabora are working on and which we fully support. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On 06/19/2012 08:00 PM, Jürgen Daubert wrote: Kay Sievers kay at vrfy.org writes: [...] We said udev *runs* alone, not that you can tweak the build system to only build it. And that is still all true. Sorry, but in your first announcement [1] this sounds quite different to me. At all I got the impression that the whole merge is more or less a try to force pepole to use systemd. Heh, looks like so. regards Juergen [1] http://article.gmane.org/gmane.linux.hotplug.devel/17392 I guess you are talking about this part? *Distributions not wishing to adopt systemd can build udev pretty much the same way as before, however should then use the systemd tarball instead of the udev tarball and package only what is necessary of the resulting build.* But it looks like this one can be interpreted in two ways: Build udev same way as before (with same deps) or build udev same way as before (same procedure). I think most of you minimalists interpreted that as the first one. But also, it isn't really fair not to allow user to choose what to build. I have nothing against systemd in LFS and source based distros. I even use it in my LFS setup, it is far more better than the sysvinit and those bash init scripts. But if you look arround, people will always mock about too much dependencies even tough those don't use anything on todays hardware. Just let them choose wether they want to BUILD (not RUN) systemd and do not force them in any way (and sorry for saying this, but this behaviour looks just like you want to force everyone to build/use systemd even if they won't), it isn't in the spirit of Free and Open Source Software. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Lennart Poettering wrote: On Fri, 15.06.12 20:06, Bryan Kadzban (br...@kadzban.is-a-geek.net) wrote: dbus libcap I am quite happy with depending on these two as it makes little sense to build an OS without it, unless you go super minimal in which case sysemd/udev are not relevant. As I said, dbus probably makes sense for a full desktop system. Most of us that are pushing for these changes are *not* running that. Only Fedora and Ubuntu seem to be pushing it this hard from what I can tell. Web/mail/whatever servers, where users never log in except possibly over ssh, have *zero* use for dbus. FS capability support is also unnecessary unless you're trying to get some kind of security certification or something; the kernel even allows disabling support entirely. (CONFIG_EXT?_FS_XATTR) m4 intltool gperf (--enable-keymap will require gperf for a udev build as well) These are only build-time deps, and hence are totally OK to have. I mean, the next thing you come up with is a patch to not require automake and use only make, just because you have a problem with dependencies? I mean, seriously. No, because I realize as well as you do that automake is only required to run automake, before configuring, before turning the git tree into the distribution package (make dist-xz or whatever). In the tarballs as distributed, automake is totally unnecessary unless the distributed tarball has a bug. Automake is not a dependency. m4, intltool, and gperf are, because configure unconditionally requires them to be present. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Hello Auke, On Fri, Jun 15, 2012 at 04:26:36AM +, Kok, Auke-jan H wrote: On Fri, Jun 15, 2012 at 2:32 AM, William Hubbs w.d.hu...@gmail.com wrote: Hello Auke, I will answer your concerns as best as I can below. On Thu, Jun 14, 2012 at 03:35:09PM -0700, Kok, Auke-jan H wrote: 1) Timing. systemd+udevd just got merged. We had a huge build system change. Let's not change it drastically again entirely now. From the point of view of a source based distro, the build system as it currently stands is broken. Upstream supports running udev without systemd, so why not building udev standalone as well, especially since there is interest in doing the work? It's not broken at all. What is broken is the assumption that one can just run `make install` willy nilly in a source distro and overwrite files in the live system. This is a design problem in ALL source based distro's (including the one I worked on for years) and can't be fixed by upstream. Source distro's should really work on doing a proper `make DESTDIR= install` or use fakeroot/chroot installs and buffer the installation of files before the real rootfs is overwritten. Not solving that is an error that the source distributions should solve, and definitely should not be the reason for an upstream project to jump to the aid of source distros. As Wulf already pointed out, gentoo already does this properly, and we also do our own sanity checks before we move the package to the live fs. This is definitely not an issue we expect upstream projects to solve other than supporting DESTDIR, which udev and systemd already do. 4) Can be maintained out of tree for now: Nothing prevents gentoo from keeping this patch out of tree for their purposes. Yes, we could, but what about exherbo, funtoo, linux from scratch and the other source based distros that may be out there? they could pull the patch from gentoo's repository. I suppose they could if they were comfortable doing that, but I tend to agree with Wulf on this; I would rather not have custom patches being shared between distros. Honestly I would rather have as few custom patches as possible; custom patches can be a headache to maintain. I think this patch would be a lot more acceptable if you drop the split Makefile.am, remove the --disable-systemd option and just create an extra make install-udev target. It would be a lot smaller too. I could rework it so I don't split up the makefiles, sure, but let me explain why the install-udev target does not solve the issue we are trying to solve. systemd has several more dependencies than udev. Because of that and because of the way the build system is setup to only do a full systemd build, I have to install all of systemd's dependencies on every gentoo user's system regardless of whether or not they are using systemd or udev standalone. What I need is a way to tell the configure script and Makefiles that I am only interested in building udev and not a full systemd build. There was another patch that came from the linux from scratch community posted on the linux-hotplug list [1]. I spoke with Kay about that patch, and he didn't sound like he liked it too much. William [1] http://www.spinics.net/lists/hotplug/msg05529.html pgpWasdXTe8M6.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
2012/6/15 William Hubbs w.d.hu...@gmail.com Hello Auke, On Fri, Jun 15, 2012 at 04:26:36AM +, Kok, Auke-jan H wrote: On Fri, Jun 15, 2012 at 2:32 AM, William Hubbs w.d.hu...@gmail.com wrote: Hello Auke, I will answer your concerns as best as I can below. On Thu, Jun 14, 2012 at 03:35:09PM -0700, Kok, Auke-jan H wrote: 1) Timing. systemd+udevd just got merged. We had a huge build system change. Let's not change it drastically again entirely now. From the point of view of a source based distro, the build system as it currently stands is broken. Upstream supports running udev without systemd, so why not building udev standalone as well, especially since there is interest in doing the work? It's not broken at all. What is broken is the assumption that one can just run `make install` willy nilly in a source distro and overwrite files in the live system. This is a design problem in ALL source based distro's (including the one I worked on for years) and can't be fixed by upstream. Source distro's should really work on doing a proper `make DESTDIR= install` or use fakeroot/chroot installs and buffer the installation of files before the real rootfs is overwritten. Not solving that is an error that the source distributions should solve, and definitely should not be the reason for an upstream project to jump to the aid of source distros. As Wulf already pointed out, gentoo already does this properly, and we also do our own sanity checks before we move the package to the live fs. This is definitely not an issue we expect upstream projects to solve other than supporting DESTDIR, which udev and systemd already do. 4) Can be maintained out of tree for now: Nothing prevents gentoo from keeping this patch out of tree for their purposes. Yes, we could, but what about exherbo, funtoo, linux from scratch and the other source based distros that may be out there? they could pull the patch from gentoo's repository. I suppose they could if they were comfortable doing that, but I tend to agree with Wulf on this; I would rather not have custom patches being shared between distros. Honestly I would rather have as few custom patches as possible; custom patches can be a headache to maintain. I think this patch would be a lot more acceptable if you drop the split Makefile.am, remove the --disable-systemd option and just create an extra make install-udev target. It would be a lot smaller too. I could rework it so I don't split up the makefiles, sure, but let me explain why the install-udev target does not solve the issue we are trying to solve. systemd has several more dependencies than udev. Because of that and because of the way the build system is setup to only do a full systemd build, I have to install all of systemd's dependencies on every gentoo user's system regardless of whether or not they are using systemd or udev standalone. That's not true. Please tell us exactly which lib is use only by systemd and not by the rest of the system. What I need is a way to tell the configure script and Makefiles that I am only interested in building udev and not a full systemd build. There was another patch that came from the linux from scratch community posted on the linux-hotplug list [1]. I spoke with Kay about that patch, and he didn't sound like he liked it too much. William [1] http://www.spinics.net/lists/hotplug/msg05529.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
2012/6/15 William Hubbs w.d.hu...@gmail.com On Fri, Jun 15, 2012 at 07:27:26PM +0800, microcai wrote: 2012/6/15 William Hubbs w.d.hu...@gmail.com systemd has several more dependencies than udev. Because of that and because of the way the build system is setup to only do a full systemd build, I have to install all of systemd's dependencies on every gentoo user's system regardless of whether or not they are using systemd or udev standalone. That's not true. Please tell us exactly which lib is use only by systemd and not by the rest of the system. At least dbus and intltool are not used by udev. There are probably more; I haven't really looked at all of the details yet. It isn't only libraries though; many things get built even when you use all of the --disable switches that are not needed on a system that is using udev standalone. but others will do use dbus and intltool. William ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
microcai wrote: 2012/6/15 William Hubbs w.d.hu...@gmail.com On Fri, Jun 15, 2012 at 07:27:26PM +0800, microcai wrote: 2012/6/15 William Hubbs w.d.hu...@gmail.com systemd has several more dependencies than udev. Because of that and because of the way the build system is setup to only do a full systemd build, I have to install all of systemd's dependencies on every gentoo user's system regardless of whether or not they are using systemd or udev standalone. That's not true. Please tell us exactly which lib is use only by systemd and not by the rest of the system. At least dbus and intltool are not used by udev. There are probably more; I haven't really looked at all of the details yet. It isn't only libraries though; many things get built even when you use all of the --disable switches that are not needed on a system that is using udev standalone. but others will do use dbus and intltool. Requirements that systemd-183, -184, and -185 all add, over and above the requirements of udev-182 (these are the deps that my initial patch relaxed the requirements on with the right flag to configure): dbus intltool m4 gperf (--enable-keymap will require gperf for a udev build as well) libcap There is also an optional dependency that systemd-185 adds (libpam) -- but it's optional, so not relevant here. Yes, some systems use dbus and FS capabilities. But they are *not* required for a Linux system, and they are not required for udev. D-Bus probably makes a full-on desktop system easier, no argument there -- but not all of us are running full-on desktop systems, either. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Hi William, On Tue, Jun 12, 2012 at 2:52 PM, William Hubbs w.d.hu...@gmail.com wrote: All, on source-based distros like gentoo or lfs, and on distros that do not Don't you have the ability to split the built package in gentoo? Lucas De Marchi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Hi Lucas, On Thu, Jun 14, 2012 at 10:48:50AM -0300, Lucas De Marchi wrote: Hi William, On Tue, Jun 12, 2012 at 2:52 PM, William Hubbs w.d.hu...@gmail.com wrote: All, on source-based distros like gentoo or lfs, and on distros that do not Don't you have the ability to split the built package in gentoo? I don't quite understand your question; there is no built package that we distribute. Gentoo is like linux from scratch or the bsd ports collection. We distribute build scripts that build the software on the end users' systems. The issue is that the udev build script now has to install all of the build time dependencies that systemd needs even though udev doesn't use them so that the configure script will not fail. Once these patches are in the tree, I do need to write one more that fixes configure.ac so that it does the systemd specific checks only when systemd is enabled, but I need more information before I can write that. I need to know which dependencies (besides dbus and intltool) are not needed by udev. Thanks, William pgpsX0BlEPBXl.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Hello Lucas,
On 14.06.2012 15:48, Lucas De Marchi wrote:
on source-based distros like gentoo or lfs, and on distros that do not
Don't you have the ability to split the built package in gentoo?
I can confirm and emphasize what William already wrote - for us
source-based distros (Exherbo in my case), there are basically two
approaches:
1. Enable building udev without the systemd parts on the build system
level. This is what William did and the cleanest solution, IMHO.
2. Disable whatever systemd-only parts that can be disabled on the build
system level (e. g. --disable-localed), build the remainder and delete
anything that's still only systemd-specific.
This is error-prone, maintenance-intensive and all around ugly - and I
can prove it ;-) by an excerpt from our udev Exheres (what William
called the build script):
# Remove everything not belonging to what-used-to-be-udev.
edo rm -r
${IMAGE}/etc/{bash_completion.d,dbus-1,modules-load.d,sysctl.d,systemd,tmpfiles.d,xdg}
edo rm -r ${IMAGE}/usr/bin/{journalctl,systemctl,systemd*}
edo rm -r ${IMAGE}/usr/include/systemd
edo rm -r ${IMAGE}/usr/*/{modules-load.d,sysctl.d,tmpfiles.d}
edo rm -r ${IMAGE}/usr/*/systemd/system
edo rm -r ${IMAGE}/usr/*/systemd/system-*
edo rm -r ${IMAGE}/usr/*/systemd/systemd-*
edo rm -r ${IMAGE}/usr/*/systemd/user
edo rm -r ${IMAGE}/usr/*/libsystemd*
edo rm -r ${IMAGE}/usr/*/pkgconfig/libsystemd*
edo rm -r ${IMAGE}/usr/${LIBDIR}/systemd
edo rm -r ${IMAGE}/usr/share/{dbus,polkit}-1
edo rm -r ${IMAGE}/usr/share/man/man{1,3,5}
edo rm -r ${IMAGE}/usr/share/man/man7/{daemon.7,sd-*,systemd*}
edo rm -r
${IMAGE}/usr/share/man/man8/{halt,pam_systemd,poweroff,reboot,runlevel,shutdown,systemd*,telinit}.8
edo rm -r ${IMAGE}/usr/share/pkgconfig/systemd.pc
It's messy as you can see and could be solved rather elegantly by
William's nice and clean work (thanks, William, I was too lazy :) ).
Of course, all this could be avoided if systemd ruled the (Linux) world
but, alas, we're not there (yet) and the way this merge was done did,
unfortunately create some unnecessary antagonism which could be eased at
least a bit if we systemd proponents could generously pat the haters'
backs and say hey, look what they did for you!. ;-)
Joking aside: Considering the elegance and neatness of systemd as a
whole, this would fit in perfectly, IMHO.
--
Best regards, Wulf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Op 14 jun. 2012, om 10:38 heeft Wulf C. Krueger het volgende geschreven: Hello Lucas, On 14.06.2012 15:48, Lucas De Marchi wrote: on source-based distros like gentoo or lfs, and on distros that do not Don't you have the ability to split the built package in gentoo? I can confirm and emphasize what William already wrote - for us source-based distros I just have to ask: what are non-source based distros based on? Pixie dust? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Thu, Jun 14, 2012 at 8:38 AM, Wulf C. Krueger philant...@exherbo.org wrote: On 14.06.2012 15:48, Lucas De Marchi wrote: on source-based distros like gentoo or lfs, and on distros that do not Don't you have the ability to split the built package in gentoo? I can confirm and emphasize what William already wrote - for us source-based distros (Exherbo in my case), there are basically two approaches: 1. Enable building udev without the systemd parts on the build system level. This is what William did and the cleanest solution, IMHO. 2. Disable whatever systemd-only parts that can be disabled on the build system level (e. g. --disable-localed), build the remainder and delete anything that's still only systemd-specific. You're forgetting the easiest answer: 3. Don't provide split udev/systemd packages and stay on udev-182 (or whatever the version was before the split). Now, I've been involved with a source-based distro myself for almost 12 years, and, at one point you just have to sell no to people who want every kitchen sink. Just because you're a source distro, doesn't mean that you should be bleeding edge, and force upstream to potentially break the build for everyone already. I'm no fan of these patches, and I'm less of a fan of them appearing *now*. Keep them in the refrigerator for 3 months, then post them. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Am Donnerstag, 14. Juni 2012, 13:40:57 schrieb Koen Kooi: Op 14 jun. 2012, om 10:38 heeft Wulf C. Krueger het volgende geschreven: I can confirm and emphasize what William already wrote - for us source-based distros I just have to ask: what are non-source based distros based on? Pixie dust? The sources are compiled right on the users' systems as opposed to binary distros where the sources are - usually - compiled by the distro who then provides pre-built binary packages to their users. One of the main differences concerning the issue at hand is that as a consequence built-time dependencies matter for users, so build everything and discard what you don't want causes more overhead than for a distributor who's probably going to have a use for the binaries that are excluded from a udev- only package. A Gentoo/LFS/etc. user who doesn't opt for systemd will need to satisfy the build deps for no benefit just to get udev. Regards, Malte ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Thu, Jun 14, 2012 at 3:57 PM, Malte Starostik li...@malte.homeip.net wrote: Am Donnerstag, 14. Juni 2012, 13:40:57 schrieb Koen Kooi: Op 14 jun. 2012, om 10:38 heeft Wulf C. Krueger het volgende geschreven: I can confirm and emphasize what William already wrote - for us source-based distros I just have to ask: what are non-source based distros based on? Pixie dust? The sources are compiled right on the users' systems as opposed to binary distros where the sources are - usually - compiled by the distro who then provides pre-built binary packages to their users. He was joking... he is one of OpenEmbedded guys ;-) The original phrasing was weird enough to deserve the joke One of the main differences concerning the issue at hand is that as a consequence built-time dependencies matter for users, so build everything and discard what you don't want causes more overhead than for a distributor who's probably going to have a use for the binaries that are excluded from a udev- only package. A Gentoo/LFS/etc. user who doesn't opt for systemd will need to satisfy the build deps for no benefit just to get udev. As Auke put very well, just keep the old version. That's the best option so far. Eventually these things will mature and your patches, or similar, can be applied. Another option I'm hoping Gentoo uses is to standardize on systemd instead of dozen of half backed utilities to do the same things. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Thu, Jun 14, 2012 at 11:54:36AM -0700, Kok, Auke-jan H wrote: 3. Don't provide split udev/systemd packages and stay on udev-182 (or whatever the version was before the split). Now, I've been involved with a source-based distro myself for almost 12 years, and, at one point you just have to sell no to people who want every kitchen sink. That is exactly my point. There are people in these distros who see systemd as a kitchen sink they don't want. However, udev is more like coreutils, which they need. Just because you're a source distro, doesn't mean that you should be bleeding edge, and force upstream to potentially break the build for everyone already. Again you make my point for me. There are folks who see systemd as bleeding edge and are not comfortable running it, but they still need udev. Define how this forces upstream to break the build. The default state of my patches is to leave things as they are unless you mess with the two added configure switches. I do not see how this breaks anything. I'm no fan of these patches, and I'm less of a fan of them appearing *now*. Keep them in the refrigerator for 3 months, then post them. Why do you hate these patches so much? Like I said, I made sure not to change the default state, so if you don't mess with the configure switches you don't change anything. William pgpuVE41T1y4T.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Thu, Jun 14, 2012 at 1:40 PM, William Hubbs w.d.hu...@gmail.com wrote: On Thu, Jun 14, 2012 at 11:54:36AM -0700, Kok, Auke-jan H wrote: 3. Don't provide split udev/systemd packages and stay on udev-182 (or whatever the version was before the split). Now, I've been involved with a source-based distro myself for almost 12 years, and, at one point you just have to sell no to people who want every kitchen sink. That is exactly my point. There are people in these distros who see systemd as a kitchen sink they don't want. However, udev is more like coreutils, which they need. or pick mdev Just because you're a source distro, doesn't mean that you should be bleeding edge, and force upstream to potentially break the build for everyone already. Again you make my point for me. There are folks who see systemd as bleeding edge and are not comfortable running it, but they still need udev. and can stay on udev-182. Define how this forces upstream to break the build. The default state of my patches is to leave things as they are unless you mess with the two added configure switches. I do not see how this breaks anything. I'm no fan of these patches, and I'm less of a fan of them appearing *now*. Keep them in the refrigerator for 3 months, then post them. Why do you hate these patches so much? Like I said, I made sure not to change the default state, so if you don't mess with the configure switches you don't change anything. I don't hate them. I think the timing is inappropriate. I don't like multiple Makefile.am's though - that's bound to be problematic further on. Nothing prevents you from staying on udev-182 for a few more weeks/months. You're not missing that much. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Hello Auke, On 14.06.2012 23:05, Kok, Auke-jan H wrote: or pick mdev Let me quote someone about mdev: Haha, mdev, yeah right. Have fun with that... greg k-h (Source: http://article.gmane.org/gmane.linux.gentoo.devel/73627) Nothing prevents you from staying on udev-182 for a few more weeks/months. You're not missing that much. What are we supposed to do in case of security issues with 182? -- Best regards, Wulf ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Thu, Jun 14, 2012 at 2:28 PM, Wulf C. Krueger philant...@exherbo.org wrote: Hello Auke, On 14.06.2012 23:05, Kok, Auke-jan H wrote: or pick mdev Let me quote someone about mdev: Haha, mdev, yeah right. Have fun with that... greg k-h (Source: http://article.gmane.org/gmane.linux.gentoo.devel/73627) Nothing prevents you from staying on udev-182 for a few more weeks/months. You're not missing that much. What are we supposed to do in case of security issues with 182? do what source distro's do best. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Thu, Jun 14, 2012 at 02:05:01PM -0700, Kok, Auke-jan H wrote: On Thu, Jun 14, 2012 at 1:40 PM, William Hubbs w.d.hu...@gmail.com wrote: That is exactly my point. There are people in these distros who see systemd as a kitchen sink they don't want. However, udev is more like coreutils, which they need. or pick mdev Would there be regressions if we do that though? I'm under the impression that mdev is a very stripped down version of udev. Just because you're a source distro, doesn't mean that you should be bleeding edge, and force upstream to potentially break the build for everyone already. Again you make my point for me. There are folks who see systemd as bleeding edge and are not comfortable running it, but they still need udev. and can stay on udev-182. unless they need something in 185, like a bug fix or something that has changed since then. Define how this forces upstream to break the build. The default state of my patches is to leave things as they are unless you mess with the two added configure switches. I do not see how this breaks anything. I'm no fan of these patches, and I'm less of a fan of them appearing *now*. Keep them in the refrigerator for 3 months, then post them. Why do you hate these patches so much? Like I said, I made sure not to change the default state, so if you don't mess with the configure switches you don't change anything. I don't hate them. I think the timing is inappropriate. I don't like multiple Makefile.am's though - that's bound to be problematic further on. What's so inappropriate about the timing, or to put it another way, why does timing matter so much? There was a patch proposed on the hotplug list which put the fixes in Makefile.am directly. I spoke with Kay on irc and he stated that he didn't like that patch. Nothing prevents you from staying on udev-182 for a few more weeks/months. You're not missing that much. That depends. are there fixes that any users need in the newer versions, or are the only differences new features? Either way, All I'm advocating for is supporting *building* udev standalone as well as *running* udev standalone. I've done the work. If there is a problem with the work I have done, I would like to know what it is so I can fix it. If there isn't a problem with it, why can't it be supported? Thanks, William pgpj2Qaj1pKlM.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Thu, Jun 14, 2012 at 02:38:08PM -0700, Kok, Auke-jan H wrote: On Thu, Jun 14, 2012 at 2:28 PM, Wulf C. Krueger philant...@exherbo.org wrote: Hello Auke, On 14.06.2012 23:05, Kok, Auke-jan H wrote: or pick mdev Let me quote someone about mdev: Haha, mdev, yeah right. Have fun with that... greg k-h (Source: http://article.gmane.org/gmane.linux.gentoo.devel/73627) Nothing prevents you from staying on udev-182 for a few more weeks/months. You're not missing that much. What are we supposed to do in case of security issues with 182? do what source distro's do best. And what is that? William pgp5mDi7sFPhl.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Hello Auke, I will answer your concerns as best as I can below. On Thu, Jun 14, 2012 at 03:35:09PM -0700, Kok, Auke-jan H wrote: 1) Timing. systemd+udevd just got merged. We had a huge build system change. Let's not change it drastically again entirely now. From the point of view of a source based distro, the build system as it currently stands is broken. Upstream supports running udev without systemd, so why not building udev standalone as well, especially since there is interest in doing the work? 2) Splitting up of Makefile.am. Sounds like a disaster waiting to happen and a reversal of the whole idea of merging the code in the first place. Irrelivant. If the maintainers ask me to rework the patches so that Makefile.am is not split, I will do that. Like I have said, I am not attempting to change the _default_ state of things. 3) Urgency: none to low. Source distro's would be perfectly fine building and maintaining the few security and bug fixes needed. AFAIK the merge only removed features in udevd. Possibly, but why should we fork udev when it isn't necessary? 4) Can be maintained out of tree for now: Nothing prevents gentoo from keeping this patch out of tree for their purposes. Yes, we could, but what about exherbo, funtoo, linux from scratch and the other source based distros that may be out there? 5) Not in the best interest of systemd as a whole, this patch only increases fragmentation. I'd rather see someone maintain the non-merged udev source with fixes only. So how does us maintaining the non-merged udev sources with fixes reduce fragmentation? That seems to be a udev fork, which definitely would not be in anyone's best interest. I point back again to what I said under 3). I don't want to fork udev or stall on udev-182 over this. I would rather work with the maintainers to stay current. William pgpissdxGHj7f.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Fri, Jun 15, 2012 at 2:32 AM, William Hubbs w.d.hu...@gmail.com wrote: Hello Auke, I will answer your concerns as best as I can below. On Thu, Jun 14, 2012 at 03:35:09PM -0700, Kok, Auke-jan H wrote: 1) Timing. systemd+udevd just got merged. We had a huge build system change. Let's not change it drastically again entirely now. From the point of view of a source based distro, the build system as it currently stands is broken. Upstream supports running udev without systemd, so why not building udev standalone as well, especially since there is interest in doing the work? It's not broken at all. What is broken is the assumption that one can just run `make install` willy nilly in a source distro and overwrite files in the live system. This is a design problem in ALL source based distro's (including the one I worked on for years) and can't be fixed by upstream. Source distro's should really work on doing a proper `make DESTDIR= install` or use fakeroot/chroot installs and buffer the installation of files before the real rootfs is overwritten. Not solving that is an error that the source distributions should solve, and definitely should not be the reason for an upstream project to jump to the aid of source distros. 2) Splitting up of Makefile.am. Sounds like a disaster waiting to happen and a reversal of the whole idea of merging the code in the first place. Irrelivant. If the maintainers ask me to rework the patches so that Makefile.am is not split, I will do that. Like I have said, I am not attempting to change the _default_ state of things. I think it's relevant. But, Kay/Lennert will eventually decide. Splitting up the file will certainly complicate maintenance, and many people frown on tricks with multiple makefiles. 3) Urgency: none to low. Source distro's would be perfectly fine building and maintaining the few security and bug fixes needed. AFAIK the merge only removed features in udevd. Possibly, but why should we fork udev when it isn't necessary? 4) Can be maintained out of tree for now: Nothing prevents gentoo from keeping this patch out of tree for their purposes. Yes, we could, but what about exherbo, funtoo, linux from scratch and the other source based distros that may be out there? they could pull the patch from gentoo's repository. I think this patch would be a lot more acceptable if you drop the split Makefile.am, remove the --disable-systemd option and just create an extra make install-udev target. It would be a lot smaller too. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Thu, Jun 14, 2012 at 11:26 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Fri, Jun 15, 2012 at 2:32 AM, William Hubbs w.d.hu...@gmail.com wrote: Hello Auke, I will answer your concerns as best as I can below. On Thu, Jun 14, 2012 at 03:35:09PM -0700, Kok, Auke-jan H wrote: 1) Timing. systemd+udevd just got merged. We had a huge build system change. Let's not change it drastically again entirely now. From the point of view of a source based distro, the build system as it currently stands is broken. Upstream supports running udev without systemd, so why not building udev standalone as well, especially since there is interest in doing the work? It's not broken at all. What is broken is the assumption that one can just run `make install` willy nilly in a source distro and overwrite files in the live system. Gentoo does not do that. It install in an image directory, and afterwars that is merged into the live system, just like RPM or .deb files. This is a design problem in ALL source based distro's (including the one I worked on for years) and can't be fixed by upstream. Source distro's should really work on doing a proper `make DESTDIR= install` or use fakeroot/chroot installs and buffer the installation of files before the real rootfs is overwritten. Gentoo does that. What William (and the Gentoo users) do not want is to compile systemd and then not merging it. It wastes time, CPU cycles, energy, and it's rude for people don't wanting systemd. Not solving that is an error that the source distributions should solve, and definitely should not be the reason for an upstream project to jump to the aid of source distros. I think you don't understand what William's patches does. 2) Splitting up of Makefile.am. Sounds like a disaster waiting to happen and a reversal of the whole idea of merging the code in the first place. Irrelivant. If the maintainers ask me to rework the patches so that Makefile.am is not split, I will do that. Like I have said, I am not attempting to change the _default_ state of things. I think it's relevant. But, Kay/Lennert will eventually decide. Splitting up the file will certainly complicate maintenance, and many people frown on tricks with multiple makefiles. As you say, it's the devs call. 3) Urgency: none to low. Source distro's would be perfectly fine building and maintaining the few security and bug fixes needed. AFAIK the merge only removed features in udevd. Possibly, but why should we fork udev when it isn't necessary? 4) Can be maintained out of tree for now: Nothing prevents gentoo from keeping this patch out of tree for their purposes. Yes, we could, but what about exherbo, funtoo, linux from scratch and the other source based distros that may be out there? they could pull the patch from gentoo's repository. I think this patch would be a lot more acceptable if you drop the split Makefile.am, remove the --disable-systemd option and just create an extra make install-udev target. It would be a lot smaller too. As you yourself said, not your call. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Hello Auke, On 15.06.2012 06:26, Kok, Auke-jan H wrote: This is a design problem in ALL source based distro's (including the one I worked on for years) and can't be fixed by upstream. Source distro's should really work on doing a proper `make DESTDIR= install` At least Gentoo and Exherbo have been doing that for years. At Exherbo, we do a lot of sanity checks before we move things from DESTDIR to the live fs so don't worry, we don't need to be aided by upstreams at that. :-) 4) Can be maintained out of tree for now: Nothing prevents gentoo from keeping this patch out of tree for their purposes. Yes, we could, but what about exherbo, funtoo, linux from scratch and the other source based distros that may be out there? they could pull the patch from gentoo's repository. We at Exherbo try very hard to avoid any downstream-only patches in order to avoid fragmentation and errors introduced by us (or any third-party). This ensures that we're usually very, very near to what upstreams expect (and support). I think this patch would be a lot more acceptable if you drop the split Makefile.am, remove the --disable-systemd option and just create an extra make install-udev target. It would be a lot smaller too. And it would mostly defeat the purpose. The only remaining benefit would be avoiding the need to manually sort things out. -- Best regards, Wulf ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
