FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-12-2012, 05:16 PM
"vivo75@gmail.com"
 
Default RFC: virtual/libudev

Il 11/07/2012 22:33, Mike Gilbert ha scritto:

On Wed, Jul 11, 2012 at 3:54 PM, William Hubbs<williamh@gentoo.org> 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.
Long time ago portage managed virtual/* ebuilds differently from the
others, it may be wise to ask to the portage developers if that's still
the case and why/what is done.
 
Old 07-26-2012, 09:44 PM
Peter Alfredsen
 
Default RFC: virtual/libudev

On Wed, Jul 11, 2012 at 11:04 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Wed, 11 Jul 2012 15:27:41 -0400
> Mike Gilbert <floppym@gentoo.org> 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.

So, since this is blocking up development and people actually solving
things, could we just have virtual/udev and be done with it? Upstream
obviously reneged on their promise to make the component parts
buildable separately, so the virtual seems like the only sane choice
right now.

/Peter
 
Old 07-26-2012, 10:08 PM
Canek Peláez Valdés
 
Default RFC: virtual/libudev

On Thu, Jul 26, 2012 at 4:44 PM, Peter Alfredsen
<peter.alfredsen@gmail.com> wrote:
> On Wed, Jul 11, 2012 at 11:04 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> On Wed, 11 Jul 2012 15:27:41 -0400
>> Mike Gilbert <floppym@gentoo.org> 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.
>
> So, since this is blocking up development and people actually solving
> things, could we just have virtual/udev and be done with it? Upstream
> obviously reneged on their promise to make the component parts
> buildable separately, so the virtual seems like the only sane choice
> right now.

Just to clarify, udev/systemd never promised "to make the component
parts buildable separately". They promised:

"we will be supporting this for a long time since it is a necessity to
make initrds (which lack systemd) work properly. 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."

Where "package only what is necessary" being the important part for Gentoo.

http://lwn.net/Articles/490413/

Certainly they don't care about source-based distributions like
Gentoo, but they never promised "to make the component parts buildable
separately".

Anyway, I also support the virtual/udev, since it's the only way for
us systemd users to not build udev twice.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingenier*a de la Computación
Universidad Nacional Autónoma de México
 
Old 07-27-2012, 02:37 AM
Duncan
 
Default RFC: virtual/libudev

Canek Pelez Valds posted on Thu, 26 Jul 2012 17:08:35 -0500 as
excerpted:

> Just to clarify, udev/systemd never promised "to make the component
> parts buildable separately". They promised:
>
> "we will be supporting this for a long time since it is a necessity to
> make initrds (which lack systemd) work properly. 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."
>
> Where "package only what is necessary" being the important part for
> Gentoo.
>
> http://lwn.net/Articles/490413/
>
> Certainly they don't care about source-based distributions like Gentoo,
> but they never promised "to make the component parts buildable
> separately".
>
> Anyway, I also support the virtual/udev, since it's the only way for us
> systemd users to not build udev twice.

Actually, they did.

1) It's no secret that gentoo is build-from-source.

2) It's no secret that gentoo is in the "distributions not wishing to
adopt systemd" class, at this point at least.

3) Gentoo's not a tiny micro-distribution, nor one based on some other
distribution. Some may argue that gentoo and its ecosystem aren't Debian
or Fedora-class, but it's certainly not too tiny to be considered a
viable candidate for that "distributions not wishing..." class, which
it's known to be in.

4) They promised, based on your quote: "can build udev pretty much the
same way as before, however should then use the systemd tarball [...] and
package only what is necessary."

5) Building the same as before does *NOT* include building systemd.

6) "Package", in the gentoo context, includes building, so ESPECIALLY
given the promise to "build udev pretty much the same as before", they
DID promise that udev would be buildable separately.

7) What they specifically did NOT promise, in fact, quite to the
contrary, was that it would be TARBALLed separately, which isn't a huge
deal for gentoo, which already has whole desktops (kde) splitting
individual packages out of monolithic combined tarballs.

8) The only way around that is if they try to argue point #3, saying
gentoo and its ecosystem is /indeed/ too small to be included in the
definition of "distributions".

9) Otherwise, at very minimum, they're failing the "build udev pretty
much the same as before" clause, if there's no provision within the
tarball (such as separate make targets and source directories, with the
systemd target not a dependency of udev target) to extract and build only
udev, without building systemd as well.



Not that such promises hold much credibility anyway... see the kde
promise (from Aaron S when he was president of KDE e.v. so as credible a
spokesperson as it gets) continued kde3 support as long as there were
users. (AFAIK, at least gnome didn't make /that/ sort of promise in the
leadup to gnome3. And no, AS cannot be properly argued to have been
referring to others, like debian with its slow release cycles, as he was
president of kde ev, not president of debian, or of the trinity project,
which AFAIK didn't even exist at the time, and didn't specify support
from OTHERS, not kde, so he was clearly speaking for kde, not for other
entities.)

--
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
 
Old 07-27-2012, 02:49 AM
Canek Pelez Valds
 
Default RFC: virtual/libudev

On Thu, Jul 26, 2012 at 9:37 PM, Duncan <1i5t5.duncan@cox.net> wrote:
[ snip ]
> 9) Otherwise, at very minimum, they're failing the "build udev pretty
> much the same as before"

./configure
make
make install

You fail to see the matter from their POV. They don't care (that much)
about building, because the distributions they care about use binary
prebuilt packages. In that sense, "build udev pretty much the same as
before" is the holly trinity of "./configure; make; make install".
Otherwise the part about "package only what is necessary" has not that
much sense.

Which again leads to the "please, add a virtual/udev" so the people
using systemd don't need to built udev twice.

Regards.
--
Canek Pelez Valds
Posgrado en Ciencia e Ingeniera de la Computacin
Universidad Nacional Autnoma de Mxico
 
Old 07-27-2012, 03:50 PM
William Hubbs
 
Default RFC: virtual/libudev

On Thu, Jul 26, 2012 at 09:49:04PM -0500, Canek Pelez Valds wrote:
> On Thu, Jul 26, 2012 at 9:37 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> [ snip ]
> > 9) Otherwise, at very minimum, they're failing the "build udev pretty
> > much the same as before"
>
> ./configure
> make
> make install
>
> You fail to see the matter from their POV. They don't care (that much)
> about building, because the distributions they care about use binary
> prebuilt packages. In that sense, "build udev pretty much the same as
> before" is the holly trinity of "./configure; make; make install".
> Otherwise the part about "package only what is necessary" has not that
> much sense.
>
> Which again leads to the "please, add a virtual/udev" so the people
> using systemd don't need to built udev twice.

Unless we add sys-apps/systemd to virtual/dev-manager.
If we do that I don't see a need for virtual/udev.

Also, I don't see how systemd users are building udev twice as it
currently stands.

William
 
Old 07-28-2012, 04:51 PM
Roy Bamford
 
Default RFC: virtual/libudev

On 2012.07.27 03:37, Duncan wrote:
[snip]
>
> Not that such promises hold much credibility anyway... see the kde
> promise (from Aaron S when he was president of KDE e.v. so as
> credible a spokesperson as it gets) continued kde3 support as long
> as there were
> users. (AFAIK, at least gnome didn't make /that/ sort of promise in
> the leadup to gnome3. And no, AS cannot be properly argued to have
> been
> referring to others, like debian with its slow release cycles, as he
> was
> president of kde ev, not president of debian, or of the trinity
> project,
> which AFAIK didn't even exist at the time, and didn't specify support
> from OTHERS, not kde, so he was clearly speaking for kde, not for
> other
> entities.)
>
> --
> 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
>
>
Duncan,

You don't want to listen to Presidents too much. Look at other real
life examples.

Would you claim that the President of the Gentoo Foundation speaks for
Gentoo?


--
Regards,

Roy Bamford
(Neddyseagoon)

Gentoo Foundation Inc. (President)
 
Old 07-29-2012, 12:14 AM
Duncan
 
Default RFC: virtual/libudev

Roy Bamford posted on Sat, 28 Jul 2012 17:51:47 +0100 as excerpted:

> You don't want to listen to Presidents too much. Look at other real
> life examples.
>
> Would you claim that the President of the Gentoo Foundation speaks for
> Gentoo?

If he were making claims of that nature, yes, barring information to the
contrary, I'd assume he had authority/authorization to do so, and would
definitely hold gentoo to a responsibility to either follow thru or
remove him for cause for making such claims without authorization to do
so (or at very minimum, to publicly repudiate the claims if they didn't
intend to follow thru). If none of that happened, I'd blame gentoo even
more than the spokesperson that made the claim, without public
repudiation.

You're right, they're PR people and as such, their claims must
(unfortunately) be taken with a grain of salt. But that doesn't
eliminate the responsibility of whatever organization to either follow
thru or repudiate, as it's the reputation and credibility of that
organization on the line if they don't.

--
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
 
Old 07-29-2012, 01:01 AM
Peter Stuge
 
Default RFC: virtual/libudev

Duncan wrote:
> the responsibility of whatever organization to either follow
> thru or repudiate, as it's the reputation and credibility of
> that organization on the line if they don't.

I think it's unreasonable to expect any third party to accept
responsibility for a receiver which is over-trusting a sender.

Receivers must be intelligent and diligent to not be fooled by
ignorant or outright malicious senders.

See also
http://en.wikipedia.org/wiki/The_War_of_the_Worlds_(radio_drama)

Society chose to make radio senders responsible by law. It's why
there are jingles. As with any free speech medium, that is not so
easy to enforce on the internet.

Just like you don't want to over-trust the guy on the corner dressed
up as a person of authority trying to disseminate whatever racist
propaganda you don't want to believe everything on the internet.

More than anything, please consider that what you have been told may
simply be a lie, and be prepared to rewind and re-evaluate the world
if you learn that this is the case. You may look like a fool for
believing someone who was telling a lie, but you'll look like a hero
for admitting that it happened and that you've learned something new.


//Peter
 
Old 08-10-2012, 07:59 AM
Michał Górny
 
Default RFC: virtual/libudev

On Tue, 10 Jul 2012 14:24:27 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Tue, Jul 10, 2012 at 05:18:00PM +0200, 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.
> >
> > 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.
>
> I'm going to ask here, because of the discussion on IRC, that you not
> commit this yet. There are issues still we need to work out wrt
> packaging systemd and udev.

So, can I commit the virtual and finally start fixing people's systems
or are we going to discuss this to the day when other options are no
longer a possibility and virtual will be necessary?

You seem still not to understand that upstream *does not care*.
And either way, merging udev and systemd will result that two, four or
six months from now users will need to manually re-adjust their @world
to have the packages split again.

--
Best regards,
Michał Górny
 

Thread Tools




All times are GMT. The time now is 09:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org