Re: [gentoo-dev] rfc: udev-rules.eclass
On 07/11/2012 10:01 PM, Ben de Groot wrote: > On 12 July 2012 07:42, William Hubbs wrote: >> On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: >>> Il 11/07/2012 21:11, William Hubbs ha scritto: I am about to release udev-186-r1, which will move everything currently in /lib/udev to /usr/lib/udev. >>> >>> Unless you're going to establish a symlink, please keep it under p.mask >>> until everything is using some common code — otherwise things _will_ break. >> >> Since multiple packages put things in /lib/udev, I'm not sure it is >> possible to establish a symlink from /lib/udev to /usr/lib/udev if >> that's what you mean; I'll look into it though. > > Couldn't you, on udev upgrade, move everything in /lib/udev to > /usr/lib/udev, and then make the symlink? Seems fairly simple > to me, but maybe I'm overlooking something? > It seems like that would work well. :) -- Thanks, Zac
Re: [gentoo-dev] rfc: udev-rules.eclass
On 12 July 2012 07:42, William Hubbs wrote: > On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: >> Il 11/07/2012 21:11, William Hubbs ha scritto: >> > I am about to release udev-186-r1, which will move everything currently >> > in /lib/udev to /usr/lib/udev. >> >> Unless you're going to establish a symlink, please keep it under p.mask >> until everything is using some common code — otherwise things _will_ break. > > Since multiple packages put things in /lib/udev, I'm not sure it is > possible to establish a symlink from /lib/udev to /usr/lib/udev if > that's what you mean; I'll look into it though. Couldn't you, on udev upgrade, move everything in /lib/udev to /usr/lib/udev, and then make the symlink? Seems fairly simple to me, but maybe I'm overlooking something? -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Portage Output / End User Experience
On 12 July 2012 06:51, Zac Medico wrote: > > Here's another related bug report, specifically about the solving the > libxml2/qt-webkit/chromium conflict: > > https://bugs.gentoo.org/show_bug.cgi?id=426222 > > -- Actually, there is another workable solution, and that is to set USE="-gstreamer -icu" for qt-webkit. Currently we enable gstreamer by default in the ebuild (as it is used for HTML5 audio/video, which is expected functionality in qt-webkit based web browsers etc.), but we are considering if we should perhaps not enable this by default. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, 2012-07-11 at 18:48 -0500, William Hubbs wrote: > On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: > > How do you plan to handle the following: > > - foo installs an udev rule > > - install foo with old udev > > - upgrade udev > > > > are rules installed by foo used by new udev ? > > No, they wouldn't be; that is a good reason to question the value of the > eclass itself. Maybe the correct way to do this is to forget the eclass > and just file bugs against packages that break having them move their > rules to the new location and set a dependency on the newer udev. > > This would have to be a rev bump for the broken packages. > > William > > > > > A. > > So, does that mean the rule itself changes or just the location change is needed? If it is just a location change, a fairly simple udev-updater script would do it. If the pkg needs to be re-compiled to work with/depend on the new udev, then a more complex script would be needed. One more along the line of python-updater/perl-cleaner. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: virtual/libudev
On Wed, Jul 11, 2012 at 09:49:18AM -0400, Michael Mol wrote > Walter Dnes (very active over in gentoo-user) has put a lot > of work into testing and documenting mdev as an alternative for > udev. There's been a good deal of success there, up to and including > it working with GNOME 2. The work's been documented on the wiki: > https://wiki.gentoo.org/wiki/Mdev I'm now testing automount under mdev. No GUI required. I hope to have a wiki page up soon. As for GNOME and KDE, they're trying to become OS's in their own right. What can I say? There are a lot of alternative desktop environments and window managers. That's my target. -- Walter Dnes
Re: [gentoo-dev] rfc: udev-rules.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/11/2012 10:50 PM, Zac Medico wrote: > On 07/11/2012 07:25 PM, Rick "Zero_Chaos" Farina wrote: >> On 07/11/2012 07:48 PM, William Hubbs wrote: >>> On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: How do you plan to handle the following: - foo installs an udev rule - install foo with old udev - upgrade udev are rules installed by foo used by new udev ? >> >>> No, they wouldn't be; that is a good reason to question the value of the >>> eclass itself. Maybe the correct way to do this is to forget the eclass >>> and just file bugs against packages that break having them move their >>> rules to the new location and set a dependency on the newer udev. >> Perhaps a new ebuild helper would be best here? It seems no one knows >> where to install udev rules in the first place (I know I didn't till a >> recent version of portage yelled at me with a QA warning). >> >> How about dorule/newrule? > > I guess then we'd need the installed udev to set an environment variable > via /etc/env.d, in order to control the location where the rules are > installed? Oh I'm sorry, I didn't mean to sound like I had an actual implementation idea in my head :-) I yield to those with greater experience on that, but yeah, env makes some sense to me. Thanks Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP/j6aAAoJEKXdFCfdEflKyJMQAJZIm4YNbmYl7EjFCU4JaNjg PJAwz1kSCCmhiQYw60FHEvdZdC4cR5v/VhBpHW0Im53yTRE6vgwjrFybze0YG9u7 UYNbz6jAZ5HYSj5CCxxCwSMricREBJcnRqZU8til8M3ayw4jI7IpRQJYOdjd923T M2b7YFW64JrGXZtpUR2Uc9KMDdgAVoMmIp5JmERTYiJxqu8RhdAWBD8Ey8xsQQIX +mT+rkoIRc5VSEnsJues59TecSDdEgYYdYGwDv81euMBTYbEbuNolImav8L2AxJZ 8k4jXPF8oVn73ehmLKjenkeiYJHVBiPycG53Q95f7Hs/YavXChtcrOg6MLsdhfTn tqrClTvOu3rvaboIfGF+QXWpi+kH0ltlPLNIyH0Q0bPCnHmwAtb43NqqprFo77/v pMkjOzRZ5rf6p+SnCE6ouwZMJS4FYSWsGKIoRwBgQm6eCj9RXNV59lFe0zW2pi9b Qf/AwR16ZeNWQovHCxYmUupGwLtEbB12sDP9hSnq+FcHAMbwvcyZamxibo9DPY+K eNc9kn7cvHu+Z3B1O3O1yfIKwYsTeVkZUMw1Sn1Y3SwtwXBNnWc/8YM41pdjSfpK bydnt8FTUeLUhLtIYzUtsN9s99S3u2rhfkPUWapeNdYYCOCMrxMl3tx52rNFggwT w03B9r0mUngc5DBzaUg6 =sg7B -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: udev-rules.eclass
On 07/11/2012 07:25 PM, Rick "Zero_Chaos" Farina wrote: > On 07/11/2012 07:48 PM, William Hubbs wrote: >> On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: >>> How do you plan to handle the following: >>> - foo installs an udev rule >>> - install foo with old udev >>> - upgrade udev >>> >>> are rules installed by foo used by new udev ? > >> No, they wouldn't be; that is a good reason to question the value of the >> eclass itself. Maybe the correct way to do this is to forget the eclass >> and just file bugs against packages that break having them move their >> rules to the new location and set a dependency on the newer udev. > Perhaps a new ebuild helper would be best here? It seems no one knows > where to install udev rules in the first place (I know I didn't till a > recent version of portage yelled at me with a QA warning). > > How about dorule/newrule? I guess then we'd need the installed udev to set an environment variable via /etc/env.d, in order to control the location where the rules are installed? -- Thanks, Zac
Re: [gentoo-dev] rfc: udev-rules.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/11/2012 07:48 PM, William Hubbs wrote: > On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: >> How do you plan to handle the following: >> - foo installs an udev rule >> - install foo with old udev >> - upgrade udev >> >> are rules installed by foo used by new udev ? > > No, they wouldn't be; that is a good reason to question the value of the > eclass itself. Maybe the correct way to do this is to forget the eclass > and just file bugs against packages that break having them move their > rules to the new location and set a dependency on the newer udev. Perhaps a new ebuild helper would be best here? It seems no one knows where to install udev rules in the first place (I know I didn't till a recent version of portage yelled at me with a QA warning). How about dorule/newrule? - -Zero > > This would have to be a rev bump for the broken packages. > > William > >> >> A. >> -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP/jWIAAoJEKXdFCfdEflKwPUP/25MRtz2WYr/ajnGIFks7Rge KFlCkIVILejW/5Bh2Ct+OUhcIcT26lENIyRi+agXxvmI6eO5RwWFz1uqinM10dc5 eQ2rdq+SzM5yrRDuy3aQRNSpemGPIT9Rnmz+/JwgqaeEbl5qMLglqIjZcU9sL675 bfFF0n6y2/HuSFY1kZ6elK5A4UBnM3LRVl6DYZlYPH0/KzSYo03qQlgrUKzODaZ6 C+d1Ctd1g8yCuMmrk2QvAuPO1dxNJHV6zWIQFmuVOZrDKxoQyiS73HwG53oeqwN1 Ig1tZo9X8co4gb8f6YcxxG6tAligqMXRbBCHwdZh1JEeLfAtA6hFxmVZ4u+Ldj9W Eco1MAGSX3qoUfoEJQeI49AcjMIkIBHR7kyvl7/IJ10xjI1QWsa9Cx2kkowaGbCw CuNlqmMLsAyOVDXdAoW/ODC/2ntNsnigv8J5m6kJ2sUzzGVzU2q1VBxkTfLQkkD4 1H0nReTSo3ilNN9ZpsBEer+xMz1xsXssDbkQGXxRi0modKYUe2z9JZ0bJweFDn2I ixEooL6D67TFS3lhkScGA0S4WO1lUO+Ih1cb6SPvGOpx+R6A+o1IYWC3utdIB1ho mGDyK8NB9fNgP3B5PAjACWPoTSs4IMRIiLBMfCIperbPNrAFGrzwJcbLnxaNy7KY l5ug3XKuM/B2yZdxyzSu =8j1W -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: > How do you plan to handle the following: > - foo installs an udev rule > - install foo with old udev > - upgrade udev > > are rules installed by foo used by new udev ? No, they wouldn't be; that is a good reason to question the value of the eclass itself. Maybe the correct way to do this is to forget the eclass and just file bugs against packages that break having them move their rules to the new location and set a dependency on the newer udev. This would have to be a rev bump for the broken packages. William > > A. > pgptwsPXj4sgH.pgp Description: PGP signature
Re: [gentoo-dev] rfc: udev-rules.eclass
Tinderbox will help you there. On Thursday, July 12, 2012, William Hubbs wrote: > On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: > > Il 11/07/2012 21:11, William Hubbs ha scritto: > > > I am about to release udev-186-r1, which will move everything currently > > > in /lib/udev to /usr/lib/udev. > > > > Unless you're going to establish a symlink, please keep it under p.mask > > until everything is using some common code — otherwise things _will_ > break. > > Since multiple packages put things in /lib/udev, I'm not sure it is > possible to establish a symlink from /lib/udev to /usr/lib/udev if > that's what you mean; I'll look into it though. > > My concern about p.mask is things tend to die there. How will we know > for sure when there will not be any breakages without putting it in > ~arch to see what breaks? > > William > >
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: > Il 11/07/2012 21:11, William Hubbs ha scritto: > > I am about to release udev-186-r1, which will move everything currently > > in /lib/udev to /usr/lib/udev. > > Unless you're going to establish a symlink, please keep it under p.mask > until everything is using some common code — otherwise things _will_ break. Since multiple packages put things in /lib/udev, I'm not sure it is possible to establish a symlink from /lib/udev to /usr/lib/udev if that's what you mean; I'll look into it though. My concern about p.mask is things tend to die there. How will we know for sure when there will not be any breakages without putting it in ~arch to see what breaks? William pgp3qWyas6PuJ.pgp Description: PGP signature
Re: [gentoo-dev] Portage Output / End User Experience
On 07/09/2012 06:05 PM, Zac Medico wrote: > On 07/09/2012 05:58 PM, Zac Medico wrote: >> On 07/09/2012 05:42 PM, Rich Freeman wrote: >>> On Mon, Jul 9, 2012 at 10:56 AM, Rich Freeman wrote: I'll test it out on a fresh install, but that will take a number of hours >>> >>> If I install chromium first, I get the following messages when I try >>> to install kde-meta: >>> The following USE changes are necessary to proceed: >>> #required by dev-db/virtuoso-server-6.1.4-r1, required by >>> dev-libs/soprano-2.7.6[virtuoso], required by >>> app-office/akonadi-server-1.7.2, >>> required by kde-base/kdepim-runtime-4.8.3-r2, required by >>> kde-base/kdepim-meta-4.8.3, required by >>> kde-base/kde-meta-4.8.3[semantic-desktop], required by kde-meta >>> (argument) >>> =sys-libs/zlib-1.2.5.1-r2 minizip >>> #required by x11-libs/qt-webkit-4.8.2[gstreamer], required by >>> kde-base/kdebase-menu-icons-4.8.3, required by >>> kde-base/kdebase-runtime-meta-4.8.3, required by >>> kde-base/kdebase-startkde-4.8.3, required by >>> kde-base/kdebase-meta-4.8.3, >>> required by kde-base/kde-meta-4.8.3, required by kde-meta (argument) >>> =dev-libs/libxml2-2.8.0_rc1 -icu >>> >>> You'll note that in this case there is nothing to suggest simply >>> enabling icu for qt-webkit. >>> >>> If I emerge kde-meta first then I get the following when I try to >>> emerge chromium: >>> The following USE changes are necessary to proceed: >>> #required by www-client/chromium-20.0.1132.43, required by >>> chromium (argument) >>> =dev-libs/libxml2-2.8.0_rc1 icu >>> >>> Then if I set the icu use flag on libxml2 it works. Apparently it >>> doesn't realize that I'm about to break qt-webkit. Portage doesn't >>> check use dependencies on existing packages when you go to rebuild >>> something? >> >> Not unless the --complete-graph option is enabled. What I'd like to do >> is to automatically enable --complete-graph mode whenever the USE of an >> installed package would change. It would be like that >> --complete-graph-if-new-ver option which is already enabled by default, >> but it would apply to USE instead of versions. > > Bug filed: > > https://bugs.gentoo.org/show_bug.cgi?id=425558 > Here's another related bug report, specifically about the solving the libxml2/qt-webkit/chromium conflict: https://bugs.gentoo.org/show_bug.cgi?id=426222 -- Thanks, Zac
Re: [gentoo-dev] inittab with SIGPWR support
> "DEP" == Diego Elio Pettenò writes: DEP> They _are_ deprecated after all. Where is that documented? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] rfc: udev-rules.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/11/2012 03:11 PM, William Hubbs wrote:
> All,
> I am about to release udev-186-r1, which will move everything currently
> in /lib/udev to /usr/lib/udev.
>
> For packages that install udev rules in ${FILESDIR}, we need an eclass
> that tests the version of udev installed on the user's system and
> installs the udev rules in the proper place. I'm not sure how many
> packages do this, so if it is a very small number of packages, it may
> not be worth the eclass. It would be good to discuss that as well as
> reviewing the proposed eclass.
I have at least half a dozen ebuilds which install rules (if you include
gentoo-x86 and pentoo overlay)
I'm guessing an eclass would be a good idea.
Thanks,
Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJP/fVvAAoJEKXdFCfdEflKQcQP/igsYucmoFmJuozob2vFyKhw
iTs/T3zFqyJXZh4k4WygQUhbrPToNkIvs24Ic7Zb90lYDlva1W24Vj4r+GBMOEEF
19q3wk3SDnZZI6ulLlpx6jTh4uzJeTl8jO3efOpHcnbXKjf3pJJGldotkYmbz1pD
ALrZywqYCpDAf2ioQFKafBnpY7coe/qyzgtOScGy680V+YIFSX0mmHl0MAFJ/jyH
V4gQvzsag227FILTRdmqMm/megYFY9POplRTVPeu/1vn6oGabPk6d+OmwR+uGoYL
8EpdG1W4RMsXGYBUsbFZWPO+q/MfJaZXa5DmwHc7z/MgNIYCj3cYmX750sWBW1EJ
GclSnu0/ykJ4I3ABMXyK3d9ZEPbjXrrEY09YVTkxd3Un1zA3LEjRSP3VBu74xvUN
oMf7MPxYuMK8ynR705j4r/WCZINKQhBRwNxUXnVrqsD0HS0qJRhZ4iYI3WzrJv7g
rGO+K8IgZLzXaWQXSocbtAlJcl1juf47O1qu2PhtNbopC+G+s1s/A3wZwjNY3LHl
Zj3nwzsijumsKid4TvHzlGtL28yPy5fQU+hniCapFr0M9QChBhLEH4VxTGqX4MzP
YEVwBEqq/QZD9T8b0Hdw7PW8KTJCX7ttemW5x27WRHHSoYP2qwoOoycixuUNpJ0j
XLt/mIBoiAiRJUHkynN4
=1aWY
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, 11 Jul 2012 15:27:41 -0400 Mike Gilbert wrote: > Personally, I think a consolidated systemd/udev package is the best > way to go here. A consolidated package means that: - every change made by udev developers would have to be reviewed by systemd team to make sure it doesn't break systemd. udev developers don't use systemd; - every change made by systemd developers would have to be reviewed by udev team to make sure it doesn't break openrc. systemd developers usually don't run openrc; - udev developers will force me to use eclasses they like and force their coding style on me; - i will force eclasses I like and my coding style on udev developers; - new udev wouldn't be able to be stabilized without systemd being stabilized at the same time (and I don't really think systemd is in any condition to go stable), - there will be a few random flags which will either work or not, depending on a state of magical switch flag, - and after all, the ebuild will be basically one big use-conditional. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, 11 Jul 2012 14:11:42 -0500
William Hubbs wrote:
> All,
> I am about to release udev-186-r1, which will move everything
> currently in /lib/udev to /usr/lib/udev.
>
> For packages that install udev rules in ${FILESDIR}, we need an eclass
> that tests the version of udev installed on the user's system and
> installs the udev rules in the proper place. I'm not sure how many
> packages do this, so if it is a very small number of packages, it may
> not be worth the eclass. It would be good to discuss that as well as
> reviewing the proposed eclass.
How do you plan to handle the following:
- foo installs an udev rule
- install foo with old udev
- upgrade udev
are rules installed by foo used by new udev ?
A.
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, Jul 11, 2012 at 02:11:42PM -0500, William Hubbs wrote:
> All,
> I am about to release udev-186-r1, which will move everything currently
> in /lib/udev to /usr/lib/udev.
>
> For packages that install udev rules in ${FILESDIR}, we need an eclass
> that tests the version of udev installed on the user's system and
> installs the udev rules in the proper place. I'm not sure how many
> packages do this, so if it is a very small number of packages, it may
> not be worth the eclass. It would be good to discuss that as well as
> reviewing the proposed eclass.
If there are no objections, I will commit this to the tree, no earlier
than 15 July UTC.
Thanks,
William
pgp5vdlZ0mMsZ.pgp
Description: PGP signature
Re: [gentoo-dev] rfc: udev-rules.eclass
Il 11/07/2012 21:11, William Hubbs ha scritto: > I am about to release udev-186-r1, which will move everything currently > in /lib/udev to /usr/lib/udev. Unless you're going to establish a symlink, please keep it under p.mask until everything is using some common code — otherwise things _will_ break. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, Jul 11, 2012 at 04:33:44PM -0400, Mike Gilbert wrote: > On Wed, Jul 11, 2012 at 3:54 PM, William Hubbs wrote: > > Thinking on this, I agree with Mike here, and to make it easier for > > maintainers so they don't have to change their dependencies, it should > > be a udev ebuild with a systemd use flag. > > An alternative to the funky udev[systemd] solution would be to replace > the entire udev ebuild with RDEPEND="sys-apps/systemd", and implement > the requisite logic in the systemd ebuild. This would effectively make > udev a virtual package without the need to modify any other packages. You would still have funkey logic in the systemd ebuild then, because you would have to have a use flag, maybe "udev-standalone" which would make it only install udev, and you would still have to deal with use flags that don't make sense without systemd being installed. William pgpHuy9q3psQz.pgp Description: PGP signature
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, Jul 11, 2012 at 3:54 PM, William Hubbs wrote: > On Wed, Jul 11, 2012 at 03:27:41PM -0400, Mike Gilbert wrote: >> Just to put a number to this, there are currently 126 packages in the >> tree with a dependency on sys-fs/udev. >> >> Personally, I think a consolidated systemd/udev package is the best >> way to go here. Short of that, the virtual + blockers seems like an >> acceptable solution. > > Thinking on this, I agree with Mike here, and to make it easier for > maintainers so they don't have to change their dependencies, it should > be a udev ebuild with a systemd use flag. > An alternative to the funky udev[systemd] solution would be to replace the entire udev ebuild with RDEPEND="sys-apps/systemd", and implement the requisite logic in the systemd ebuild. This would effectively make udev a virtual package without the need to modify any other packages.
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, Jul 11, 2012 at 02:11:42PM -0500, William Hubbs wrote:
> For packages that install udev rules in ${FILESDIR}, we need an eclass
> that tests the version of udev installed on the user's system and
> installs the udev rules in the proper place. I'm not sure how many
> packages do this, so if it is a very small number of packages, it may
> not be worth the eclass.
I do this in sci-misc/comedi-headers (wtk overlay). Actually, I had
just been installing the rules into /etc/udev/rules.d, because I
hadn't read the docs thoroughly enough. +1 for an eclass to handle
this for me ;).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, Jul 11, 2012 at 03:27:41PM -0400, Mike Gilbert wrote: > Just to put a number to this, there are currently 126 packages in the > tree with a dependency on sys-fs/udev. > > Personally, I think a consolidated systemd/udev package is the best > way to go here. Short of that, the virtual + blockers seems like an > acceptable solution. Thinking on this, I agree with Mike here, and to make it easier for maintainers so they don't have to change their dependencies, it should be a udev ebuild with a systemd use flag. William pgp40hv8AYgm1.pgp Description: PGP signature
[gentoo-dev] rfc: udev-rules.eclass
All,
I am about to release udev-186-r1, which will move everything currently
in /lib/udev to /usr/lib/udev.
For packages that install udev rules in ${FILESDIR}, we need an eclass
that tests the version of udev installed on the user's system and
installs the udev rules in the proper place. I'm not sure how many
packages do this, so if it is a very small number of packages, it may
not be worth the eclass. It would be good to discuss that as well as
reviewing the proposed eclass.
Thanks,
William
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/systemd.eclass,v 1.11 2012/01/07
17:53:47 mgorny Exp $
# @ECLASS: udev-rules.eclass
# @MAINTAINER:
# udev-b...@gentoo.org
# @BLURB: helper functions to install udev rules
# @DESCRIPTION:
# This eclass provides a set of functions to install udev rules.
# With versions of udev prior to 186, udev rules for extra packages were
# installed in /lib/udev/rules.d, but with newer versions they are installed in
# /usr/lib/udev/rules.d.
# @EXAMPLE:
#
# @CODE
# inherit udev-rules
#
# src_install() {
# udev_dorules "${FILESDIR}"/foo.rules "${FILESDIR}"/bar.rules
# udev_newrules "${FILESDIR}"/old.rules.name baz.rules
# }
# @CODE
case ${EAPI:-0} in
0|1|2|3|4) ;;
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
esac
# @FUNCTION: _udev_get_rulesdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed udev rules directory.
_udev_get_rulesdir() {
local dir
if has_version '
pgpQTVhkDkOnL.pgp
Description: PGP signature
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, Jul 11, 2012 at 2:26 PM, Thomas Sachau wrote: > Michał Górny schrieb: >> On Tue, 10 Jul 2012 21:23:39 +0200 >> Thomas Sachau wrote: >> >>> Michał Górny schrieb: Hello, all. Since nowadays udev is bundled within systemd, we start having two libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making the long story short, I would like to introduce a virtual for libudev which would pull in either of those two. There are three USE flags used in conditionals when depending on udev: - gudev - for glib wrapper on udev, - hwdb - to pull in hwids, - static-libs. The former two were previously provided by 'extras' USE flag, and the third was unconditional. I'm attaching an example virtual/libudev which does the job. Sadly, because of the 'extras' compatibility it's a big ugly conditional. An alternative would be to provide separate virtual/libudev and virtual/libgudev; and maybe changing ebuilds not to depend on [hwids] but rather pull in sys-apps/hwids directly (since that's what the flag does). What are you thoughts? >>> >>> As discussed on IRC, there is still no consensus for installing the >>> udev files with systemd, which is the beginning for the block and the >>> virtual. So we should first sort that point out, before we even start >>> to think about an ebuild for an udev virtual. >> >> Do you have a technical or policy reason prohibiting me from maintaining >> a systemd ebuild following the upstream policies? > > How about this simple one: The udev ebuild does already install udev, so > why should we have another package also installing the same thing, > resulting in a blocker, the need to switch from one package to another > and the need for package maintainers to switch their dependencies? Just to put a number to this, there are currently 126 packages in the tree with a dependency on sys-fs/udev. > Since William already said, that he will move the udev installation to > /usr/lib, i dont see any technical reason left to not simply depend on > the udev ebuild. > And if you fear issues about not knowing which parts to install, then > just check the files installed by the udev ebuild, remove them from your > systemd ebuild and you are done. This means that systemd users end up building the udev components twice, and throwing away the second copy. You don't seem to care about this, but I think it is a valid concern. I am guessing that systemd is or will become very sensitive to any change in udev's API, so each systemd version would have to depend exactly on the corresponding udev version. This means that a systemd version bump could be stuck waiting on the corresponding udev version. I also wonder if incompatibilities may be introduced by passing different build options in the udev and systemd ebuilds due to having different use flags enabled, for example. This can be worked around with use-deps of course, but it is yet another pain point for the systemd maintainer. If there were a way to tell the systemd build system to build against the "system udev", that might avoid the issue, but I doubt systemd upstream would implement such a thing. Personally, I think a consolidated systemd/udev package is the best way to go here. Short of that, the virtual + blockers seems like an acceptable solution.
Re: [gentoo-dev] RFC: virtual/libudev
Michał Górny schrieb: > On Tue, 10 Jul 2012 21:23:39 +0200 > Thomas Sachau wrote: > >> Michał Górny schrieb: >>> Hello, all. >>> >>> Since nowadays udev is bundled within systemd, we start having two >>> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making >>> the long story short, I would like to introduce a virtual for >>> libudev which would pull in either of those two. >>> >>> There are three USE flags used in conditionals when depending on >>> udev: >>> - gudev - for glib wrapper on udev, >>> - hwdb - to pull in hwids, >>> - static-libs. >>> >>> The former two were previously provided by 'extras' USE flag, >>> and the third was unconditional. >>> >>> I'm attaching an example virtual/libudev which does the job. Sadly, >>> because of the 'extras' compatibility it's a big ugly conditional. >>> >>> An alternative would be to provide separate virtual/libudev >>> and virtual/libgudev; and maybe changing ebuilds not to depend on >>> [hwids] but rather pull in sys-apps/hwids directly (since that's >>> what the flag does). >>> >>> What are you thoughts? >> >> As discussed on IRC, there is still no consensus for installing the >> udev files with systemd, which is the beginning for the block and the >> virtual. So we should first sort that point out, before we even start >> to think about an ebuild for an udev virtual. > > Do you have a technical or policy reason prohibiting me from maintaining > a systemd ebuild following the upstream policies? How about this simple one: The udev ebuild does already install udev, so why should we have another package also installing the same thing, resulting in a blocker, the need to switch from one package to another and the need for package maintainers to switch their dependencies? Since William already said, that he will move the udev installation to /usr/lib, i dont see any technical reason left to not simply depend on the udev ebuild. And if you fear issues about not knowing which parts to install, then just check the files installed by the udev ebuild, remove them from your systemd ebuild and you are done. > >> So for now: A clear no, i am against adding a virtual/libudev ebuild. > > Please give the rationale. I did above. So if you still want to install udev yourself, please give the rationale for doing so. And neither upstream naming nor a big upstream tarball nor the Makefile do force this, so please exclude those points. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH systemd.eclass] Do not install systemd units on BSD
Index: systemd.eclass === RCS file: /var/cvsroot/gentoo-x86/eclass/systemd.eclass,v retrieving revision 1.11 diff -u -B -d -u -p -r1.11 systemd.eclass --- systemd.eclass 7 Jan 2012 17:53:47 - 1.11 +++ systemd.eclass 11 Jul 2012 17:56:56 - @@ -34,6 +34,10 @@ esac DEPEND="! signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: old udev versions
On Wed, Jul 11, 2012 at 12:42:04PM +0800, Ben de Groot wrote: > On 11 July 2012 02:30, William Hubbs wrote: > > All, > > > > the last thread started by mgorny has prompted me to ask here on the > > list which versions of udev we really need in the tree. > > Personally, I'm holding on to 171. I have masked >=181 because of > bad decisions upstream and I want to see how the situation will > stabilize. > > Since 171 is the latest stable, I would think most of our users are > on this version anyway. > > Since upstream seems to be unwilling to work with us, I think > we should seriously consider doing a fork. I know there are > other distros like Debian and Slackware who would be happy > to join us in that effort. I'm not interested in a fork at this time. I think we can continue making udev work for us as is, and the way upstream is doing things isn't affecting binary package based distros, so we would basically be on our own. The deal is that upstream supports *running* udev separately, but not *building* it separately [1]. Their approach works wonderfully if you are a binary package based distro, so I'm not sure Debian, Slackware, etc would really have any incentive to join a fork at this point. William [1] http://freedesktop.org/wiki/Software/systemd/MinimalBuilds pgpWkIspVxAgb.pgp Description: PGP signature
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, Jul 11, 2012 at 10:52 AM, Michał Górny wrote: > Are you aware how much additional code and maintenance does keeping two > hacked build systems introduce? One of things I don't want to do is > keeping the list of *all other* systemd targets up-to-date, > and installing them all by hand. I'd assumed that Thomas was representing some lack of consensus among the systemd team. If the systemd team really is aligned with wanting to install udev within their build then the virtual makes sense to me. It would have no impact on other packages and would make things easier for systemd. That said, we need to keep an eye on any continuing drift between udev and our needs. If there is a fork and one does the /usr move then we need to figure out some way of handling that. Just seems like part of the continuing "Androidification" of Linux. It really is the year of the linux desktop (or phone), but linux only in the sense of the kernel that is being run. Between the /usr move, systemd, upstart, wayland, unity, GnomeOS, udev, and who knows what is next, it seems like we're going to end up with 20 medium-sized distros and no piece of code runs reliably on more than one or two of them. Linux will end up having less in common with itself than it currently has in common with Solaris. Rich
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, 11 Jul 2012 10:35:32 -0400 Rich Freeman wrote: > On Wed, Jul 11, 2012 at 10:09 AM, Michał Górny > wrote: > > On Tue, 10 Jul 2012 21:23:39 +0200 > > Thomas Sachau wrote: > >> As discussed on IRC, there is still no consensus for installing the > >> udev files with systemd, which is the beginning for the block and > >> the virtual. So we should first sort that point out, before we > >> even start to think about an ebuild for an udev virtual. > > > > Do you have a technical or policy reason prohibiting me from > > maintaining a systemd ebuild following the upstream policies? > > > > It sounds like we have two packages that COULD provide udev - udev and > systemd. If we decide for both of them to provide udev then we need a > virtual and they need to block (which should make switching more fun). > If we decide to keep using the udev package to install udev then we > don't need a virtual. No, switching is no fun. It's plain simple with weak blockers. It's even their purpose. > I'd view this like the split kde ebuilds. Upstream ships a monster > tarball, and we install it in chunks. Just because upstream ships > both packages together doesn't require us to install them together. > From a code-reuse standpoint and ease of transition standpoint it > makes sense to keep them split, as long as we can have everybody > continue to use the same udev codebase. Are you aware how much additional code and maintenance does keeping two hacked build systems introduce? One of things I don't want to do is keeping the list of *all other* systemd targets up-to-date, and installing them all by hand. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, Jul 11, 2012 at 10:09 AM, Michał Górny wrote: > On Tue, 10 Jul 2012 21:23:39 +0200 > Thomas Sachau wrote: >> As discussed on IRC, there is still no consensus for installing the >> udev files with systemd, which is the beginning for the block and the >> virtual. So we should first sort that point out, before we even start >> to think about an ebuild for an udev virtual. > > Do you have a technical or policy reason prohibiting me from maintaining > a systemd ebuild following the upstream policies? > It sounds like we have two packages that COULD provide udev - udev and systemd. If we decide for both of them to provide udev then we need a virtual and they need to block (which should make switching more fun). If we decide to keep using the udev package to install udev then we don't need a virtual. I'd view this like the split kde ebuilds. Upstream ships a monster tarball, and we install it in chunks. Just because upstream ships both packages together doesn't require us to install them together. >From a code-reuse standpoint and ease of transition standpoint it makes sense to keep them split, as long as we can have everybody continue to use the same udev codebase. Rich
Re: [gentoo-dev] Re: RFC: virtual/libudev
On Wed, Jul 11, 2012 at 10:06 AM, Rich Freeman wrote: > On Wed, Jul 11, 2012 at 9:49 AM, Michael Mol wrote: >> Walter Dnes (very active over in gentoo-user) has put a lot of work >> into testing and documenting mdev as an alternative for udev. There's >> been a good deal of success there, up to and including it working with >> GNOME 2. The work's been documented on the wiki: >> https://wiki.gentoo.org/wiki/Mdev > > Unless you plan to stay on Gnome 2 forever or fork it you might want > to consider that Gnome at some point is going to require systemd, let > alone udev. Whether that happens or not remains to be seen. > > Not that mdev doesn't have its uses, but you're probably not going to > be running future releases of Gnome on it. I only mention Gnome 2 as an indicator of an example of system complexity support achieved. I don't know what's going to happen with future app interdependency with udev and systemd any more than anyone else. What's the generic laconic description of what udev and mdev do? Hotplug event handler? Is there a significant reason Gentoo shouldn't support selecting between such handlers? At the point where there's discussion between using systemd's in-tree copy of udev and a fork of udev, it seems appropriate to examine the possibility of a more general selection mechanism. Admittedly, with increased generality comes increased complexity. I don't know exactly where increased long-term complexity would come from, but my first guess would be redirecting where packages dependent on hooking the hotplug handler place their scripts. Anything else I can think of sounds more like an up-front effort cost, and not a long-term one. -- :wq
Re: [gentoo-dev] RFC: virtual/libudev
On Tue, 10 Jul 2012 21:23:39 +0200 Thomas Sachau wrote: > Michał Górny schrieb: > > Hello, all. > > > > Since nowadays udev is bundled within systemd, we start having two > > libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making > > the long story short, I would like to introduce a virtual for > > libudev which would pull in either of those two. > > > > There are three USE flags used in conditionals when depending on > > udev: > > - gudev - for glib wrapper on udev, > > - hwdb - to pull in hwids, > > - static-libs. > > > > The former two were previously provided by 'extras' USE flag, > > and the third was unconditional. > > > > I'm attaching an example virtual/libudev which does the job. Sadly, > > because of the 'extras' compatibility it's a big ugly conditional. > > > > An alternative would be to provide separate virtual/libudev > > and virtual/libgudev; and maybe changing ebuilds not to depend on > > [hwids] but rather pull in sys-apps/hwids directly (since that's > > what the flag does). > > > > What are you thoughts? > > As discussed on IRC, there is still no consensus for installing the > udev files with systemd, which is the beginning for the block and the > virtual. So we should first sort that point out, before we even start > to think about an ebuild for an udev virtual. Do you have a technical or policy reason prohibiting me from maintaining a systemd ebuild following the upstream policies? > So for now: A clear no, i am against adding a virtual/libudev ebuild. Please give the rationale. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: virtual/libudev
On Wed, Jul 11, 2012 at 9:49 AM, Michael Mol wrote: > Walter Dnes (very active over in gentoo-user) has put a lot of work > into testing and documenting mdev as an alternative for udev. There's > been a good deal of success there, up to and including it working with > GNOME 2. The work's been documented on the wiki: > https://wiki.gentoo.org/wiki/Mdev Unless you plan to stay on Gnome 2 forever or fork it you might want to consider that Gnome at some point is going to require systemd, let alone udev. Whether that happens or not remains to be seen. Not that mdev doesn't have its uses, but you're probably not going to be running future releases of Gnome on it. Rich
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, 11 Jul 2012 11:31:03 +0300 Samuli Suominen wrote: > On 07/10/2012 06:18 PM, Michał Górny wrote: > > Hello, all. > > > > Since nowadays udev is bundled within systemd, we start having two > > libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making > > the long story short, I would like to introduce a virtual for > > libudev which would pull in either of those two. > > sys-apps/systemd with USE="systemd" where USE="-systemd" would only > install udev > > and a virtual/udev for handling the migration period: > > || ( sys-apps/systemd > the way it's currently in tree is not the way to go, and is somewhat > obstructing the systemd maintaince. as in, I can see where you are > coming with this thread. I don't understand how it obstructs systemd maintenance. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: virtual/libudev
On Wed, Jul 11, 2012 at 9:02 AM, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 11/07/12 06:40 AM, Rich Freeman wrote:
>> On Wed, Jul 11, 2012 at 4:27 AM, Duncan <1i5t5.dun...@cox.net>
>> wrote:
>>> Being able to choose not to run systemd at all? If there's no
>>> need to build systemd, than what it requires is irrelevant.
>>
>> I think this discussion is getting sidetracked.
>>
>> This didn't start out as a discussion about whether everybody
>> should have to have systemd on their systems - the answer to that
>> is no.
>>
>> The question is whether we should have a virtual for udev. Right
>> now we're not sure how that is going to be packaged as far as
>> systemd is concerned, so it is premature to make that decision.
>> However, if we do decide to fork udev then that means we'd almost
>> certainly need to have a virtual. At that point we'd have two
>> different udev implementations in the tree - the fork and the one
>> that comes bundled with systemd.
>>
>> Where things get dicey is if the two udev implementations start to
>> diverge and packages need to behave differently depending on which
>> one is installed - that would become a bit of a mess. Hopefully it
>> won't come to that.
>>
>
>
> ..although it possibly could come to that, if the fork maintains
> installation in /{bin,sbin,lib} while systemd-udev follows the
> upstream move to /usr/{bin,sbin,lib}
I don't know the devs' familiarity or positions on it (or the history
of it here), but it's potentially relevant if you're looking at udev
and the /{bin,sbin,lib} vs /usr/{bin,sbin,lib} split.
Walter Dnes (very active over in gentoo-user) has put a lot of work
into testing and documenting mdev as an alternative for udev. There's
been a good deal of success there, up to and including it working with
GNOME 2. The work's been documented on the wiki:
https://wiki.gentoo.org/wiki/Mdev
--
:wq
[gentoo-dev] dev-libs/ffcall is looking for a new maintainer
This package historically belongs to the gnustep herd, but ffcall support in gnustep has been deprecated for some time now in favor of libffi (in fact the USE-flag may go away soon) Also, I do not have the time to work on it, although it requires a bit of work: * switch to "new" upstream (recommending to grab CVS tarballs) at http://www.gnu.org/software/libffcall/ * a bunch of opened issues (parallel make/install, ldflags, execstacks, ...): https://bugs.gentoo.org/buglist.cgi?quicksearch=ffcall So if you are interested, please add yourself to metadata.xml (and remove gnustep herd) and start bug sqashing. As a bonus, you will still have a backup herd (common-lisp), thoug a real maintainer would be great Reverse RDEPEND for dev-libs/ffcall: dev-lang/gforth-0.7.0 dev-lisp/clisp-2.47-r1 dev-lisp/clisp-2.48-r1 dev-lisp/clisp-2.48-r2 gnustep-base/gnustep-base-1.20.1:!libffi gnustep-base/gnustep-base-1.24.0-r1:!libffi -- Bernard Cafarelli (Voyageur) Gentoo developer (NX, GNUstep, net-misc, llvm/clang, ...)
Re: [gentoo-dev] Re: RFC: virtual/libudev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/07/12 06:40 AM, Rich Freeman wrote:
> On Wed, Jul 11, 2012 at 4:27 AM, Duncan <1i5t5.dun...@cox.net>
> wrote:
>> Being able to choose not to run systemd at all? If there's no
>> need to build systemd, than what it requires is irrelevant.
>
> I think this discussion is getting sidetracked.
>
> This didn't start out as a discussion about whether everybody
> should have to have systemd on their systems - the answer to that
> is no.
>
> The question is whether we should have a virtual for udev. Right
> now we're not sure how that is going to be packaged as far as
> systemd is concerned, so it is premature to make that decision.
> However, if we do decide to fork udev then that means we'd almost
> certainly need to have a virtual. At that point we'd have two
> different udev implementations in the tree - the fork and the one
> that comes bundled with systemd.
>
> Where things get dicey is if the two udev implementations start to
> diverge and packages need to behave differently depending on which
> one is installed - that would become a bit of a mess. Hopefully it
> won't come to that.
>
..although it possibly could come to that, if the fork maintains
installation in /{bin,sbin,lib} while systemd-udev follows the
upstream move to /usr/{bin,sbin,lib}
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAk/9eUkACgkQ2ugaI38ACPAFiwD/fAERfjHE0kHItPuBnCqH+669
flblkcc4/rMkAOQk8GUA/3MKU1j374JmcF9omXDFDJcq4SEJszKNL3tJGjgs0i0v
=dahJ
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: virtual/libudev
On Wed, Jul 11, 2012 at 4:27 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Being able to choose not to run systemd at all? If there's no need to > build systemd, than what it requires is irrelevant. I think this discussion is getting sidetracked. This didn't start out as a discussion about whether everybody should have to have systemd on their systems - the answer to that is no. The question is whether we should have a virtual for udev. Right now we're not sure how that is going to be packaged as far as systemd is concerned, so it is premature to make that decision. However, if we do decide to fork udev then that means we'd almost certainly need to have a virtual. At that point we'd have two different udev implementations in the tree - the fork and the one that comes bundled with systemd. Where things get dicey is if the two udev implementations start to diverge and packages need to behave differently depending on which one is installed - that would become a bit of a mess. Hopefully it won't come to that. Rich
Re: [gentoo-dev] RFC: virtual/libudev
Il 11/07/2012 10:03, Samuli Suominen ha scritto: > > > so knowing all that, I would simply kill USE=hwdb and always pull in the > package, as it used to be for avoiding pulling in the actual > pciutils/usbutils with their dependencies, but is not worth for the > separate hwids package anymore Sounds good to me — the hwids package itself should be easy to deal with, and it solves the whole issue of depending on the "big" packages. Although I also have a replacement of mine (mini-hwdata) when the hwids themselves are overkill. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: virtual/libudev
On 07/10/2012 06:18 PM, Michał Górny wrote: Hello, all. Since nowadays udev is bundled within systemd, we start having two libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making the long story short, I would like to introduce a virtual for libudev which would pull in either of those two. sys-apps/systemd with USE="systemd" where USE="-systemd" would only install udev and a virtual/udev for handling the migration period: || ( sys-apps/systemd the way it's currently in tree is not the way to go, and is somewhat obstructing the systemd maintaince. as in, I can see where you are coming with this thread.
Re: [gentoo-dev] Re: RFC: virtual/libudev
On Wed, 11 Jul 2012 08:27:48 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Michał Górny posted on Wed, 11 Jul 2012 09:15:10 +0200 as excerpted: > > > On Wed, 11 Jul 2012 12:51:50 +0800 Ben de Groot > > wrote: > > >> When upstream moved the udev sources to the systemd repo, they > >> promised that udev would continue to be able to be used separately > >> from systemd. We should hold them to that promise. > >> > >> If they break their promise (as it seems they are bent on doing), > >> then we should go ahead with the fork as discussed earlier. I'm > >> sure other distros such as Debian and Slackware would be happy to > >> join us in that effort. > > > > If we fork, then I would expect systemd to actually require its own > > udev which means that systemd would need to build it anyway. What's > > the point? > > > Being able to choose not to run systemd at all? If there's no need > to build systemd, than what it requires is irrelevant. Who forces you to do otherwise? I really don't see what this thread is all about. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: virtual/libudev
Michał Górny posted on Wed, 11 Jul 2012 09:15:10 +0200 as excerpted: > On Wed, 11 Jul 2012 12:51:50 +0800 Ben de Groot > wrote: >> When upstream moved the udev sources to the systemd repo, they promised >> that udev would continue to be able to be used separately from systemd. >> We should hold them to that promise. >> >> If they break their promise (as it seems they are bent on doing), then >> we should go ahead with the fork as discussed earlier. I'm sure other >> distros such as Debian and Slackware would be happy to join us in that >> effort. > > If we fork, then I would expect systemd to actually require its own udev > which means that systemd would need to build it anyway. What's the > point? Being able to choose not to run systemd at all? If there's no need to build systemd, than what it requires is irrelevant. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] RFC: virtual/libudev
On 07/10/2012 06:18 PM, Michał Górny wrote: An alternative would be to provide separate virtual/libudev and virtual/libgudev; and maybe changing ebuilds not to depend on [hwids] but rather pull in sys-apps/hwids directly (since that's what the flag does). USE=hwdb should be reviewed: >udev-180 was bumped without taking care of the switch, and the ebuild got QA warning then it was fixed for something else, and the `use_enable` was dropped to supress the warning and then hwids was made into a separate package so knowing all that, I would simply kill USE=hwdb and always pull in the package, as it used to be for avoiding pulling in the actual pciutils/usbutils with their dependencies, but is not worth for the separate hwids package anymore What are you thoughts?
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, 11 Jul 2012 12:51:50 +0800 Ben de Groot wrote: > On 11 July 2012 03:23, Thomas Sachau wrote: > > Michał Górny schrieb: > >> Hello, all. > >> > >> Since nowadays udev is bundled within systemd, we start having two > >> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making > >> the long story short, I would like to introduce a virtual for > >> libudev which would pull in either of those two. > >> [...] > >> What are you thoughts? > > > > As discussed on IRC, there is still no consensus for installing the > > udev files with systemd, which is the beginning for the block and > > the virtual. So we should first sort that point out, before we even > > start to think about an ebuild for an udev virtual. > > > > So for now: A clear no, i am against adding a virtual/libudev > > ebuild. > > Me too. > > When upstream moved the udev sources to the systemd repo, they > promised that udev would continue to be able to be used separately > from systemd. We should hold them to that promise. > > If they break their promise (as it seems they are bent on doing), > then we should go ahead with the fork as discussed earlier. I'm sure > other distros such as Debian and Slackware would be happy to > join us in that effort. If we fork, then I would expect systemd to actually require its own udev which means that systemd would need to build it anyway. What's the point? -- Best regards, Michał Górny signature.asc Description: PGP signature
