[gentoo-dev] Unified nVidia Driver Ebuild ready for testing

[gentoo-dev] Unified nVidia Driver Ebuild ready for testing

[Peter]

To Gentoo nVidia users:

We are in the process of developing and testing
a unified nVidia driver ebuild. When implemented,
it will replace the nvidia-kernel, nvidia-glx, and 
nvidia-settings ebuilds. It will also add the utility
nvidia-xconfig.

We would like your help in evaluating, testing, and
commenting on this approach. Please locate the latest
nvidia ebuild at: 

http://bugs.gentoo.org/show_bug.cgi?id=116085

The download package for the new ebuild is at:
http://bugs.gentoo.org/attachment.cgi?id=75389

This is the very latest nVidia 8178 driver. Please
be sure and review the nVidia changelog and readme.
If your fonts are abnormally small, see Appendix Y
and the nVidia forums for info on DPI. See

http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14

for specific news and info about the nVidia drivers
for linux.

Since this is a developmental ebuild, it is NOT currently
in portage. If you would like to try it out, please
follow these simple instructions:

1) Untar the file into /usr/local/portage/x11-drivers
(if your portage overlay is in a different location,
adjust accordingly).

2) exit all window managers

3) unmerge nvidia-kernel, nvidia-glx, and nvidia-settings
(emerge -C .....) This ebuild will NOT install if any
other nVidia ebuilds are installed.

4) edit /etc/portage/package.keywords and add

x11-drivers/nvidia-drivers   ~x86 (or ~amd64). 
Other arches are not supported. Sorry.

5) emerge nvidia-drivers.

This will load the kernel module, glx support, nvidia-
settings and -xconfig all in one swoop.

NOTE: Modular X support is not yet implemented.

If you have comments, notice a bug, or if you have 
suggestions for improvement, PLEASE post to the existing
bug report:

http://bugs.gentoo.org/show_bug.cgi?id=116085.

Please DO NOT report bugs about the upstream driver. If the
driver does not work, then see the nVidia news forum.

We hope you will find this approach a more streamlined and
easy implementation for nVidia.

Thanks for your participation and feedback.

Peter Hyman on behalf of the nVidia devs.



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unified nVidia Driver Ebuild ready for testing

[Mike Frysinger]

On Fri, Dec 23, 2005 at 12:41:45PM -0500, Peter wrote:
> We are in the process of developing and testing
> a unified nVidia driver ebuild. When implemented,
> it will replace the nvidia-kernel, nvidia-glx, and 
> nvidia-settings ebuilds. It will also add the utility
> nvidia-xconfig.

issues:
 - people rebuild nvidia-kernel when they upgrade/change their kernel
   version; rebuilding the other packages in this case is pointless
 - nvidia-kernel/nvidia-glx may be released in parallel, but 
   the nvidia-settings package is not last i checked (never even heard
   of nvidia-xconfig) ... whats the point in unifying things when they
   arent the same version ... you'll hit the same issue as above, if
   a new version of nvidia-settings is put out, people will have to
   pointlessly rebuild the other nvidia packages
-mike
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Peter]

On Fri, 23 Dec 2005 18:47:40 +0000, Mike Frysinger wrote:

> On Fri, Dec 23, 2005 at 12:41:45PM -0500, Peter wrote:
>> We are in the process of developing and testing
>> a unified nVidia driver ebuild. When implemented,
>> it will replace the nvidia-kernel, nvidia-glx, and 
>> nvidia-settings ebuilds. It will also add the utility
>> nvidia-xconfig.
> 
> issues:
>  - people rebuild nvidia-kernel when they upgrade/change their kernel
>    version; rebuilding the other packages in this case is pointless
>  - nvidia-kernel/nvidia-glx may be released in parallel, but 
>    the nvidia-settings package is not last i checked (never even heard
>    of nvidia-xconfig) ... whats the point in unifying things when they
>    arent the same version ... you'll hit the same issue as above, if
>    a new version of nvidia-settings is put out, people will have to
>    pointlessly rebuild the other nvidia packages
> -mike

All noted. nvidia-settings and -xconfig are included in binary form with
the pkg?.run files. -xconfig is married to a particular version of the
driver. Settings too will change rarely, if at all, without a driver
update.

Total compile time, as noted in the bug report, for me was 1' 10" using an
XP 2500 oc'ed to 2800. The glx modules don't compile at all since they're
not open source. Updating only kernel, and not glx is a dangerous business
in any case. By unifying the ebuilds, we are merely duplicating what
nvidia provides in its install packages. We're not doing anything they
aren't.

FWIW, I have already contacted upstream and suggested _strongly_ that they
include the source for settings and xconfig with the pkg?.run files.

Your feedback is appreciated. Please post to the bug report any additional
comments.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Stuart Herbert]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

Hi Peter,

On Fri, 2005-12-23 at 14:05 -0500, Peter wrote:
> in any case. By unifying the ebuilds, we are merely duplicating what
> nvidia provides in its install packages. We're not doing anything they
> aren't.

Who is "we" please?  As you're a non-dev, it would be polite to
introduce yourself at the top of emails like this for the benefit of
those who don't want to wade through that bug.  You probably didn't
intend it this way, but your lack of introduction has distracted from
the work you're trying to do here.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Unified nVidia Driver Ebuild ready for testing

[Peter]

On Fri, 23 Dec 2005 20:13:45 +0000, Stuart Herbert wrote:

> Hi Peter,
> 
> On Fri, 2005-12-23 at 14:05 -0500, Peter wrote:
>> in any case. By unifying the ebuilds, we are merely duplicating what
>> nvidia provides in its install packages. We're not doing anything they
>> aren't.
> 
> Who is "we" please?  
augustus, spyderous, azarah, me and testers.

> As you're a non-dev, it would be polite to
> introduce yourself at the top of emails like this for the benefit of
> those who don't want to wade through that bug.  You probably didn't
> intend it this way, but your lack of introduction has distracted from
> the work you're trying to do here.

I was just doing as I was asked. Post an invitation for testing and
comments. I did not think I had to do anything more other than document
what this project is about. As for my lack of etiquette, I apologize.

I'm peter, a user. I contribute ebuilds. Rox primarily, avfs, nvidia,
libtrash, fuse, python-alsa plus I've commented on many more
(enlightenment, eterm, etc,). I also rewrote the rox.eclass. In
addition, I have made small contributions to several OS projects over the
last seven years. I enjoy participating.

This particular project _was_ my idea. I posted the bug with a first stab at
the unified ebuild. augustus took it up and is now in charge. I truly felt
there were two problems that this corrected. 

1) the existing ebuild code was a bit messy and outdated. Unifying the
ebuilds forced a cleanup long overdue
2) the concept of splitting a product seemed overly complex and
unnecessary.

The whole purpose of opening a bug on it was to have the concept reviewed,
improved, or disregarded.

I did _not_ do this project in order to defend it or try and justify it.
If it fills a need, then it will be ported. If not, it won't. But just
because something has always been done a certain way does not mean that
it is the right way or it can't change. The ati drivers come as one
package so why can't nvidia. The "extra" package ati has are far larger
and far more complex than the TWO nvidia extra programs. The idea of
having an nvidia kernel ebuild and a separate nvidia glx ebuild is not
logical. glx depends on kernel, but not the other way around? Good luck
running a glx app withing it! nvidia-settings and xconfig are so small
they are insignificant in terms of compile time. 1' 10".

And, consider from the user's pov. Wouldn't it be simpler and easier to
say "emerge nvidia-drivers" and be done with it?

So, that's it. Sorry for the non-intro, but I wasn't asked to do that.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unified nVidia Driver Ebuild ready for testing

[Stephen P. Becker]

Since nobody else has asked, I will.  What is the point?  What problem 
are you trying to solve with this ebuild?  As far as I can tell, there 
is no point, other than trying to sound like you are doing something 
important.

I can tell you that I would be disappointed if this replaces the current 
ebuilds, because I really don't need to reinstall nvidia-settings and 
nvidia-glx every time I build a new kernel.


> We hope you will find this approach a more streamlined and
> easy implementation for nVidia.

I don't particularly see how it is easier.


> Thanks for your participation and feedback.
> 
> Peter Hyman on behalf of the nVidia devs.

The nVidia devs?  Is upstream pushing this?  Why?  What is the point?

-Steve
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Peter]

On Fri, 23 Dec 2005 14:43:59 -0500, Stephen P. Becker wrote:

> Since nobody else has asked, I will.  What is the point?  What problem 
> are you trying to solve with this ebuild?  As far as I can tell, there 
> is no point, other than trying to sound like you are doing something 
> important.

Sigh...The point was to take 3, potentially 4, ebuilds and make 1. As for
trying to sound anything, that is not true. Why not bring that up with
Kris who has taken up this project.

> 
> I can tell you that I would be disappointed if this replaces the current 
> ebuilds, because I really don't need to reinstall nvidia-settings and 
> nvidia-glx every time I build a new kernel.
> 

That's why we are having this dialog. When I proposed doing a unified
ebuild, the objective always was to get and encourage feedback. If you are
happy keeping up with three ebuilds, then that is feedback we need to
have. BTW, please post these comments to the bug report.

> 
>> We hope you will find this approach a more streamlined and easy
>> implementation for nVidia.
> 
> I don't particularly see how it is easier.

But many do. This mirrors the approach nvidia takes.

> 
> 
>> Thanks for your participation and feedback.
>> 
>> Peter Hyman on behalf of the nVidia devs.
> 
> The nVidia devs?  Is upstream pushing this?  Why?  What is the point?

No, nVidia devs are Kris and the x11-driver group.
> 
> -Steve

BTW, I don't want to get into a multi-threaded debate about the
merits or drawbacks to this in this forum. Bug reports or comments are
encouraged since that way everyone involved will see it. I was just asked
to post the invite.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Stephen P. Becker]

> Sigh...The point was to take 3, potentially 4, ebuilds and make 1.

Well, nvidia-xconfig should probably be part of hte nvidia-settings 
ebuild, but I really don't think the drivers and kernel module should be 
included.  Why not create a meta-ebuild which pulls all of these ebuilds 
in, so that it is easy to install everything, yet you don't break the 
ability to re-install the kernel module everytime somebody compiled a 
new kernel.


> BTW, please post these comments to the bug report.

Bug reports are not a forum for discussion.


>>>We hope you will find this approach a more streamlined and easy
>>>implementation for nVidia.
>>
>>I don't particularly see how it is easier.
> 
> 
> But many do. This mirrors the approach nvidia takes.

Why should we care what approach nvidia takes?  I'm looking for reasons 
here.


> No, nVidia devs are Kris and the x11-driver group.
> BTW, I don't want to get into a multi-threaded debate about the
> merits or drawbacks to this in this forum. Bug reports or comments are
> encouraged since that way everyone involved will see it. I was just asked
> to post the invite.

See my comment above.  Mailing lists are for discussion, and bugzilla is 
for fixing bugs.

-Steve

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Niklas Bolander]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

On Friday 23 December 2005 20:59, Peter wrote:
> > I can tell you that I would be disappointed if this replaces the current
> > ebuilds, because I really don't need to reinstall nvidia-settings and
> > nvidia-glx every time I build a new kernel.
>
> That's why we are having this dialog. When I proposed doing a unified
> ebuild, the objective always was to get and encourage feedback. If you are
> happy keeping up with three ebuilds, then that is feedback we need to
> have. BTW, please post these comments to the bug report.
>
> >> We hope you will find this approach a more streamlined and easy
> >> implementation for nVidia.
> >
> > I don't particularly see how it is easier.
>
> But many do. This mirrors the approach nvidia takes.
>

As another non-dev/user I must say that three separate ebuilds is preferable. 
The kernel ebuild must be recompiled every time I change kernel while the glx 
only needs to be installed once. Finaly, I have rather bad experiences of 
nvidia-settings and would like to avoid them at all.

Wouldn't it be more sensible to make a nvidia-meta build that pulled in all 
three if the goal is pure simplicity? 

Merry Christmas btw.

/Niklas

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Dale]

Niklas Bolander wrote:

>On Friday 23 December 2005 20:59, Peter wrote:
>  
>
>>>I can tell you that I would be disappointed if this replaces the current
>>>ebuilds, because I really don't need to reinstall nvidia-settings and
>>>nvidia-glx every time I build a new kernel.
>>>      
>>>
>>That's why we are having this dialog. When I proposed doing a unified
>>ebuild, the objective always was to get and encourage feedback. If you are
>>happy keeping up with three ebuilds, then that is feedback we need to
>>have. BTW, please post these comments to the bug report.
>>
>>    
>>
>>>>We hope you will find this approach a more streamlined and easy
>>>>implementation for nVidia.
>>>>        
>>>>
>>>I don't particularly see how it is easier.
>>>      
>>>
>>But many do. This mirrors the approach nvidia takes.
>>
>>    
>>
>
>As another non-dev/user I must say that three separate ebuilds is preferable. 
>The kernel ebuild must be recompiled every time I change kernel while the glx 
>only needs to be installed once. Finaly, I have rather bad experiences of 
>nvidia-settings and would like to avoid them at all.
>
>Wouldn't it be more sensible to make a nvidia-meta build that pulled in all 
>three if the goal is pure simplicity? 
>
>Merry Christmas btw.
>
>/Niklas
>  
>
I have to agree.  Do it sort of like KDE, with kde, kde-meta or as 
seperate packages.  Have it so you can pull in all three in one emerge 
command but have the option to do it seperately as well.  I have only 
emerged glx once and do the nvidia-kernel when I change kernels.  I 
really don't have any use for the settings package, as long as my GUI 
works anyway.

Just give us some options.  We'll be happy then.

Dale
:-)

Now to shut my mouth on the dev list.  My foot doesn't fit very well.  O_O

-- 
To err is human, I'm most certainly human.

I have four rigs:

1:  Home built; Abit NF7 ver 2.0 w/ AMD 2500+ CPU, 1GB of ram and right now two 80GB hard drives.
2:  Home built; Iwill KK266-R w/ AMD 1GHz CPU, 256MBs of ram and a 4GB drive.
3:  Home built; Gigabyte GA-71XE4 w/ 800MHz CPU, 128MBs of ram and a 2.5GB drive.
4:  Compaq Proliant 6000 Server w/ Quad 200MHz CPUs, 128MBs of ram and a 4.3GB SCSI drive.

All run Gentoo Linux, all run folding. #1 is my desktop, 2, 3, and 4 are set up as servers.  

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Unified nVidia Driver Ebuild ready for testing

[Peter]

On Sat, 24 Dec 2005 03:16:53 -0600, Dale wrote:

> Niklas Bolander wrote:
snip...

> I have to agree.  Do it sort of like KDE, with kde, kde-meta or as
> seperate packages.  Have it so you can pull in all three in one emerge
> command but have the option to do it seperately as well.  I have only
> emerged glx once and do the nvidia-kernel when I change kernels.  I
> really don't have any use for the settings package, as long as my GUI
> works anyway.
> 
> Just give us some options.  We'll be happy then.
> 
> 
THAT is a very reasonable comment!

Thank you Dale and everyone else who commented. Please do not think this
was an attempt to shove anything down anyone's throat. It was not. That's
why this thread was started and that is why we wanted feedback.

Those who commented that settings and xconfig are optional _are_ correct.
They are in no way required and indeed many people would not use them even
if they could. Since they were so small, I wanted to see if unifying the
ebuilds would make sense.

Reasonable people can debate whether or not having glx installed each time
a kernel is updated is worth it. It is _NOT_ required, but glx compiles
nothing. They are libraries copied into a directory tree. So, there _is_
overhead when glx is installed -- such as unpacking the tarball and going
through all the emerge preamble stuff. Having it wedded to kernel
driver can save time even if glx is not required at the time.

AND LET ME APOLOGIZE for the ebuild borking. A symlink directory
was changed inadvertently between 8174 and 8178. Something changed in
portage 2.0.53 which blew up the download section. I posted workarounds at
the bug report.

http://bugs.gentoo.org/show_bug.cgi?id=116085#c37
http://bugs.gentoo.org/show_bug.cgi?id=116085#c42

Please continue to provide additional feedback to the bug report.

Happy Hanukkah, Merry Christmas. Trivia fact: first time since 1959 they
start on the same day. 

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Unified nVidia Driver Ebuild ready for testing

[Dale]

Peter wrote:

>On Sat, 24 Dec 2005 03:16:53 -0600, Dale wrote:
>
>  
>
>>Niklas Bolander wrote:
>>    
>>
>snip...
>
>  
>
>>I have to agree.  Do it sort of like KDE, with kde, kde-meta or as
>>seperate packages.  Have it so you can pull in all three in one emerge
>>command but have the option to do it seperately as well.  I have only
>>emerged glx once and do the nvidia-kernel when I change kernels.  I
>>really don't have any use for the settings package, as long as my GUI
>>works anyway.
>>
>>Just give us some options.  We'll be happy then.
>>
>>
>>    
>>
>THAT is a very reasonable comment!
>  
>

And maybe a thought as well.  It sounds doable to me.  Removes foot from 
mouth.  LOL

>Thank you Dale and everyone else who commented. Please do not think this
>was an attempt to shove anything down anyone's throat. It was not. That's
>why this thread was started and that is why we wanted feedback.
>  
>

I didn't feel that way.  The only rig of mine that uses nvidia stuff is 
a fast one anyway.  It doesn't matter to me but it may to someone that 
is forced to use a 200MHz rig with only 64MBs of ram.  A laptop comes to 
mind as well.

>Those who commented that settings and xconfig are optional _are_ correct.
>They are in no way required and indeed many people would not use them even
>if they could. Since they were so small, I wanted to see if unifying the
>ebuilds would make sense.
>  
>

I would not object to the settings package as long as it does not change 
the defaults when it installs.  For me the default works.  Why mess with 
what works?

Dale
:-)

-- 
To err is human, I'm most certainly human.

I have four rigs:

1:  Home built; Abit NF7 ver 2.0 w/ AMD 2500+ CPU, 1GB of ram and right now two 80GB hard drives.
2:  Home built; Iwill KK266-R w/ AMD 1GHz CPU, 256MBs of ram and a 4GB drive.
3:  Home built; Gigabyte GA-71XE4 w/ 800MHz CPU, 128MBs of ram and a 2.5GB drive.
4:  Compaq Proliant 6000 Server w/ Quad 200MHz CPUs, 128MBs of ram and a 4.3GB SCSI drive.

All run Gentoo Linux, all run folding. #1 is my desktop, 2, 3, and 4 are set up as servers.  

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Unified nVidia Driver Ebuild ready for testing

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On Saturday 24 December 2005 12:34, Peter wrote:
> THAT is a very reasonable comment!

Not at all. "Meta ebuilds" are a provisional and fugly workaround as long as 
we have to wait for proper sets and only to be used for a larger set of 
packages. Wrapping three or four ebuilds with another one, just for the sake 
of lazy people having only to emerge a single ebuild is ridiculous. The only 
valid point in the original idea to merge the nvidia-* packages is to reduce 
the overall number of packages in the repository. As you heard the voices 
against it, ranging from none to valid reasons, everything left is to bury 
the idea and to close the bug.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing

[Peter]

On Sat, 24 Dec 2005 13:09:36 +0100, Carsten Lohrke wrote:

> On Saturday 24 December 2005 12:34, Peter wrote:
>> THAT is a very reasonable comment!
> 
> Not at all. "Meta ebuilds" are a provisional and fugly workaround as long as 
> we have to wait for proper sets and only to be used for a larger set of 
> packages. Wrapping three or four ebuilds with another one, just for the sake 
> of lazy people having only to emerge a single ebuild is ridiculous. The only 
> valid point in the original idea to merge the nvidia-* packages is to reduce 
> the overall number of packages in the repository. As you heard the voices 
> against it, ranging from none to valid reasons, everything left is to bury 
> the idea and to close the bug.
> 
> 
> Carsten

Would you please add the comments to the bug report? Or, may I copy them?
Please advise.

Also, I find it absolutely fascinating that the only people against this
concept are devs, and the only people for it are users. Remember that
users are your customers. Every effort should be made to keep them happy.

If you are against meta ebuilds, what is your opinion on KDE? Instead on 9
(or so) packages, there are now over 250! Are 250 separate ebuilds better?
I cannot think of another distro that slices up KDE that way. Meta
ebuilds at least allow the user the ability to opt out of trying to
decide which ebuilds to emerge!

I always used to use CVS to update my KDE source tree, then compile only
the changed modules. I could have a whole updated KDE inside an hour. Now
that is performance!

Here, with the unified nvidia, the intent was to REDUCE ebuilds and
simplify installation process. I thought the recommendation of a meta
nvidia ebuild is a worthy one worth consideration.

IMHO sometimes the desire to fine tune things and optimize things goes a
little over the edge. nVidia upstream combines all the products together
in their .run files. There is minimal time difference between having the
entire suite installed versus each one individually. And, from a user's
point of view, what could be simpler?

Anyway, I appreciate your feedback. 

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

On Saturday 24 December 2005 13:50, Peter wrote:
> Also, I find it absolutely fascinating that the only people against this
> concept are devs, and the only people for it are users. Remember that
> users are your customers. Every effort should be made to keep them happy.
Considering that we aren't paid, I think that every _affordable_ effort should 
be made, but making more complex maintainership for devs just to satisfy a 
couple of users, when the advantages are really minimal, it's not exactly a 
good choice, IMHO.

> Here, with the unified nvidia, the intent was to REDUCE ebuilds and
> simplify installation process. I thought the recommendation of a meta
> nvidia ebuild is a worthy one worth consideration.
nvidia-glx depends on nvidia-kernel already, no? That would be enough, for me.

> nVidia upstream combines all the products together 
> in their .run files. There is minimal time difference between having the
> entire suite installed versus each one individually.
Well depends how you see it.
If you just build it when you update the drivers, yeah there's a minimal 
difference.
But if you have more than one kernel (for whatever reason), and you want to 
have the latest kernel on all of them, it's way faster to just use 
nvidia-kernel.

Then there's the point I've already said, about mixing the kernel-level with 
generic userland stuff: for Gentoo/FreeBSD I need it to be split, or I'd have 
to recreate a copy ebuild especially for FBSD... and that not only sucks from 
an user POV but also from a maintenance POV.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Re: Re: Unified nVidia Driver Ebuild ready for testing

[Peter]

On Sat, 24 Dec 2005 14:09:01 +0100, Diego 'Flameeyes' Pettenò wrote:

snip...
>> nVidia upstream combines all the products together 
>> in their .run files. There is minimal time difference between having the
>> entire suite installed versus each one individually.
> Well depends how you see it.
> If you just build it when you update the drivers, yeah there's a minimal 
> difference.
> But if you have more than one kernel (for whatever reason), and you want to 
> have the latest kernel on all of them, it's way faster to just use 
> nvidia-kernel.

Not really. glx does not compile at all and the entire pkg file has to be
extracted. Same amount of files being processed...

> 
> Then there's the point I've already said, about mixing the kernel-level
> with generic userland stuff: for Gentoo/FreeBSD I need it to be split,
> or I'd have to recreate a copy ebuild especially for FBSD... and that
> not only sucks from an user POV but also from a maintenance POV.

FBSD is a problem already. It's not even a valid arch at the moment
(x86-fbsd). Work is ongoing to pull in the required sources:
ftp://download.nvidia.com/freebsd/1.0-8178/NVIDIA-FreeBSD-x86-1.0.8178.tar.gz
and get it integrated. Anything current with fbsd is at the best a
complete hack.

The making of those sources differs substantially from current. Perhaps
you could help evaluate it?

Then, there is one last issue you did not consider. If nvidia releases a
new driver, there is no dependency from kernel -> glx. It's possible that
a user could update kernel, and NOT glx. That would be bad. Here,
everything will be kept in sync guaranteed.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Unified nVidia Driver Ebuild ready for testing

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

On Saturday 24 December 2005 16:31, Peter wrote:
> Not really. glx does not compile at all and the entire pkg file has to be
> extracted. Same amount of files being processed...
No, because the glx part files needs to be processed by portage, too, and 
that's something that takes time, especially now that portage uses paxutils 
to find texrels and company.

> FBSD is a problem already. It's not even a valid arch at the moment
I'm working on it, the problem is that we had to get rid of x86-fbsd keyword 
in arch.list to avoid devs wasting time from running repoman for x86-fbsd 
profiles.
An alternative is to check CHOST.

>Anything current with fbsd is at the best a 
> complete hack.
In GLX? I don't really think so, a part a couple of special cases, the most of 
the ebuild works in the same manner for both of them, there are name changes 
due to the different versions.
And for the kernel module, it's _completely_ different, that's why I don't 
want the Linux module and the FreeBSD module to be in the same ebuild. I have 
an nvidia-freebsd package on gentoo/alt overlay.

> Then, there is one last issue you did not consider. If nvidia releases a
> new driver, there is no dependency from kernel -> glx.
This would make it a circular dep, I would say to poke portage devs about 
that.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[R Hill]

Diego 'Flameeyes' Petten wrote:
> On Saturday 24 December 2005 16:31, Peter wrote:
>> Not really. glx does not compile at all and the entire pkg file has to be
>> extracted. Same amount of files being processed...
> No, because the glx part files needs to be processed by portage, too, and 
> that's something that takes time, especially now that portage uses paxutils 
> to find texrels and company.

dirtyepic ~ $ genlop -t nvidia-glx
 * media-video/nvidia-glx

     Sat Dec 24 03:53:35 2005 >>> media-video/nvidia-glx-1.0.8178
       merge time: 14 seconds.


:o


--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing

[Jon Portnoy]

On Sat, Dec 24, 2005 at 07:50:51AM -0500, Peter wrote:
> 
> Also, I find it absolutely fascinating that the only people against this
> concept are devs, and the only people for it are users. Remember that
> users are your customers. Every effort should be made to keep them happy.

  customer
       n : someone who pays for goods or services [syn: {client}]

When did we start selling Gentoo?

(Admittedly we sell optical media via the Gentoo Store, but the software 
is still free-as-in-beer)

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 3217 bytes --]

On Saturday 24 December 2005 13:50, Peter wrote:
> Would you please add the comments to the bug report? Or, may I copy them?
> Please advise.

Feel free to do so.

> Also, I find it absolutely fascinating that the only people against this
> concept are devs, and the only people for it are users. Remember that
> users are your customers. Every effort should be made to keep them happy.

The only valid issue I read about against a single nvidia-driver package was 
Diego's regarding FreeBSD. On the other hand having packages split or merged 
only because it can be done, doesn't make much sense. Regarding happiness, 
merry x-mas and best wishes to everyone, but I care about maintainability in 
the first place. You may be interested in GLEP 21¹, a very user friendly 
approach to easily group user defined packages.

> If you are against meta ebuilds, what is your opinion on KDE? Instead on 9
> (or so) packages, there are now over 250! Are 250 separate ebuilds better?
> I cannot think of another distro that slices up KDE that way. Meta
> ebuilds at least allow the user the ability to opt out of trying to
> decide which ebuilds to emerge!

The split was due and having meta packages of some sort was necessary due to 
the amount of packages. The problems are present though: re-emerging and 
un-emerging meta packages doesn't affect their child packages. For reasons 
why the split ebuilds are an advantage please refer to The KDE Split Ebuilds 
HOWTO². The big downside of (the large number of) split packages is the 
affect on the code base of the stable Portage versions (and the current 
layout of the repository), which apparently is not created having scalability 
issues in mind.

> I always used to use CVS to update my KDE source tree, then compile only
> the changed modules. I could have a whole updated KDE inside an hour. Now
> that is performance!

But this has nothing to do with providing a large user base with a reasonable 
stable set of packages.

> Here, with the unified nvidia, the intent was to REDUCE ebuilds and
> simplify installation process. I thought the recommendation of a meta
> nvidia ebuild is a worthy one worth consideration.

As explained above, it isn't.

> IMHO sometimes the desire to fine tune things and optimize things goes a
> little over the edge. nVidia upstream combines all the products together
> in their .run files. There is minimal time difference between having the
> entire suite installed versus each one individually. And, from a user's
> point of view, what could be simpler?
>
> Anyway, I appreciate your feedback.

If Diego could explain what the FreeBSD problem is and if he can resolve it, 
personally I don't see a valid reason against having a unified nvidia-driver 
package. I assume all the steps Portage is doing to install those packages 
(and uninstall previous versions) will take more time than having it bundled 
in a single ebuild, anyways. But raising the number of packages by a crappy 
meta ebuild (sorry, lazy users don't count) - no.


Carsten


[1] http://www.gentoo.org/proj/en/glep/glep-0021.html
[2] http://www.gentoo.org/doc/en/kde-split-ebuilds.xml#doc_chap3

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing

[Jean-Francois Gagnon Laporte]

On 12/24/05, Peter <pete4abw@comcast.net> wrote:
> On Sat, 24 Dec 2005 13:09:36 +0100, Carsten Lohrke wrote:
>
> > On Saturday 24 December 2005 12:34, Peter wrote:
> >> THAT is a very reasonable comment!
> >
> > Not at all. "Meta ebuilds" are a provisional and fugly workaround as long as
> > we have to wait for proper sets and only to be used for a larger set of
> > packages. Wrapping three or four ebuilds with another one, just for the sake
> > of lazy people having only to emerge a single ebuild is ridiculous. The only
> > valid point in the original idea to merge the nvidia-* packages is to reduce
> > the overall number of packages in the repository. As you heard the voices
> > against it, ranging from none to valid reasons, everything left is to bury
> > the idea and to close the bug.
> >
> >
> > Carsten
>
<snip>
>
> Also, I find it absolutely fascinating that the only people against this
> concept are devs, and the only people for it are users. Remember that
> users are your customers. Every effort should be made to keep them happy.
>
This is a voluntary based distro. Gentoo devs are users too only with
added responsability (there's more to it but just for the sake of
simplicity ...). I cannot speak for the maintenance  side of things
though.

> If you are against meta ebuilds, what is your opinion on KDE? Instead on 9
> (or so) packages, there are now over 250! Are 250 separate ebuilds better?
> I cannot think of another distro that slices up KDE that way. Meta
> ebuilds at least allow the user the ability to opt out of trying to
> decide which ebuilds to emerge!
>
Please check this url : http://packages.debian.org/stable/kde/.
Actually, Gentoo was one of the very rare distro that was bundling
kde-base, kde-network etc all in one big package.

> I always used to use CVS to update my KDE source tree, then compile only
> the changed modules. I could have a whole updated KDE inside an hour. Now
> that is performance!
>
That is the whole point of the split kde ebuilds. It should be even
faster than your method when conf-cache is fully implemented. I don't
remember if it is finished though. It is also automated, less error
prone and intergrated in our favorite package manager. Thank you KDE
team for the good work by the way.

> Here, with the unified nvidia, the intent was to REDUCE ebuilds and
> simplify installation process. I thought the recommendation of a meta
> nvidia ebuild is a worthy one worth consideration.
>
It simplifies the installation so to speak but for many gentoo users
that changes their kernel often it's a pain. How would your ebuild
react to module-rebuild ?

> IMHO sometimes the desire to fine tune things and optimize things goes a
> little over the edge. nVidia upstream combines all the products together
> in their .run files. There is minimal time difference between having the
> entire suite installed versus each one individually. And, from a user's
> point of view, what could be simpler?
>
I agree with this but from a user point of view having both would be
better. A meta ebuild with correct use flags that pulls the necessary
dependency but leaves us with the flexibilty of easy kernel mangling
is good even if it's a "a provisional and fugly workaround" when it's
all we have for this type of situation. Albeit, when you remove the
meta ebuild it doesn't remove it's dependency except if you run the
very scary depclean and for good reasons. The user would be left with
all the modules lying around when he though that it was removed.

> Anyway, I appreciate your feedback.
>
Sure no problem. As a long time Gentoo user, I chose this distro for
it's flexibilty and modularity not it's simplicity. Gentoo devs have a
habit (policy ?) of following upstream as long as it fits well with
the distro. Moreover, bugzilla is not used for discussing proposals.

wkr and happy holidays

Jean-Francois
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing

[lnxg33k]

I'm just a user, but I personally would prefer the three separate ebuilds. If a
meta-ebuild was included as an additional way to build, that'd be fine. I
update whenever a new version comes out, but only build -kernel after updating
the kernel. This makes sense as being the most efficient way to go. As for the
"extra" packages, I don't use them and don't intend to. I know they may be
small, but that's just one more file/build that I don't have to worry about and
that clutters the system; I'm very picky about my system. Just my opinion on
this. Have a safe holiday break.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On Sat, 24 Dec 2005 07:50:51 -0500 Peter <pete4abw@comcast.net> wrote:
| Also, I find it absolutely fascinating that the only people against
| this concept are devs, and the only people for it are users. Remember
| that users are your customers. Every effort should be made to keep
| them happy.

Hardly surprising. Our 'customers' don't always know what's best for
them, especially when it comes down to low level issues like this one.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

Peter wrote:
> Also, I find it absolutely fascinating that the only people against this
> concept are devs, and the only people for it are users. 

Please see Message-ID: <43AD1205.1050403@exceedtech.net> (for those
using MUAs that suck, it's "Date: Sat, 24 Dec 2005 03:16:53 -0600",
"From: Dale <dalek@exceedtech.net>" in this thread).

> If you are against meta ebuilds, what is your opinion on KDE? Instead on 9
> (or so) packages, there are now over 250! Are 250 separate ebuilds better?
> I cannot think of another distro that slices up KDE that way. Meta
> ebuilds at least allow the user the ability to opt out of trying to
> decide which ebuilds to emerge!

You seem to be confused by split ebuilds and meta ebuilds.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing

[Rodolfo Boer]

Alle 13:50, sabato 24 dicembre 2005, Peter ha scritto:
> Also, I find it absolutely fascinating that the only people against this
> concept are devs, and the only people for it are users. Remember that
> users are your customers. Every effort should be made to keep them happy.

As a user, I wouldn't normally write to this list, but you asked for our 
opinions.

Apart from the fact that I upgrade the kernel more often than I upgrade 
nvidia-kernel, and as many have pointed out this means reistallyng glx, 
nvidia-settings and nvidia-xconfig even if not needed, there's also another 
important point:

This unified ebuild will lead me to upgrade the package even if it is just a 
rev-bump for issues related to (e.g.) nvidia-settings, which I don't even 
use!! Or do you expect that users always look at the Changelog to see if the 
upgrade really applies to them. How could this "improve the user's 
experience"?

Some may not agree with the idea of turning it in a meta-ebuild, but if this 
must really be done, I think that would be the only way to keep everyone 
satisfied.

-- 
Move -- Proudly abusing Gentoo Base System version 1.12.0_pre12
        Linux 2.6.14-gentoo-r5
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Curtis Napier]

Dale wrote:
> Niklas Bolander wrote:
> 
>> On Friday 23 December 2005 20:59, Peter wrote:
>>  
>>
>>>> I can tell you that I would be disappointed if this replaces the 
>>>> current
>>>> ebuilds, because I really don't need to reinstall nvidia-settings and
>>>> nvidia-glx every time I build a new kernel.
>>>>     
>>>
>>> That's why we are having this dialog. When I proposed doing a unified
>>> ebuild, the objective always was to get and encourage feedback. If 
>>> you are
>>> happy keeping up with three ebuilds, then that is feedback we need to
>>> have. BTW, please post these comments to the bug report.
>>>
>>>   
>>>
>>>>> We hope you will find this approach a more streamlined and easy
>>>>> implementation for nVidia.
>>>>>       
>>>>
>>>> I don't particularly see how it is easier.
>>>>     
>>>
>>> But many do. This mirrors the approach nvidia takes.
>>>
>>>   
>>
>>
>> As another non-dev/user I must say that three separate ebuilds is 
>> preferable. The kernel ebuild must be recompiled every time I change 
>> kernel while the glx only needs to be installed once. Finaly, I have 
>> rather bad experiences of nvidia-settings and would like to avoid them 
>> at all.
>>
>> Wouldn't it be more sensible to make a nvidia-meta build that pulled 
>> in all three if the goal is pure simplicity?
>> Merry Christmas btw.
>>
>> /Niklas
>>  
>>
> I have to agree.  Do it sort of like KDE, with kde, kde-meta or as 
> seperate packages.  Have it so you can pull in all three in one emerge 
> command but have the option to do it seperately as well.  I have only 
> emerged glx once and do the nvidia-kernel when I change kernels.  I 
> really don't have any use for the settings package, as long as my GUI 
> works anyway.
> 
> Just give us some options.  We'll be happy then.
> 

Ditto. A unified build would make more work for my tired old CPU. A meta 
build would be better, give us the choice to pull it all in or one at a 
time like kde.


ps. I appreciate the original intention of trying to clean this up. Thanks!
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[fire-eyes]

As an end user, I would prefer the ebuilds kept seperately. Also right
now, nvidia-settings will not compile for some of us, which would result
in a single merge failing:

http://bugs.gentoo.org/show_bug.cgi?id=114649
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Dale]

fire-eyes wrote:

>As an end user, I would prefer the ebuilds kept seperately. Also right
>now, nvidia-settings will not compile for some of us, which would result
>in a single merge failing:
>
>http://bugs.gentoo.org/show_bug.cgi?id=114649
>  
>
Looks like I started something.  O_O  I finally said something someone 
agrees with me on, on the dev list no less.  WOW < falls out of chair, 
hits head and dies > 

Later

Dale
:-)

-- 
To err is human, I'm most certainly human.

I have four rigs:

1:  Home built; Abit NF7 ver 2.0 w/ AMD 2500+ CPU, 1GB of ram and right now two 80GB hard drives.
2:  Home built; Iwill KK266-R w/ AMD 1GHz CPU, 256MBs of ram and a 4GB drive.
3:  Home built; Gigabyte GA-71XE4 w/ 800MHz CPU, 128MBs of ram and a 2.5GB drive.
4:  Compaq Proliant 6000 Server w/ Quad 200MHz CPUs, 128MBs of ram and a 4.3GB SCSI drive.

All run Gentoo Linux, all run folding. #1 is my desktop, 2, 3, and 4 are set up as servers.  

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unified nVidia Driver Ebuild ready for testing

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On Friday 23 December 2005 18:41, Peter wrote:
> We would like your help in evaluating, testing, and
> commenting on this approach. Please locate the latest
> nvidia ebuild at:
I thought that we (gentoo devs) were trying to split the modules from ebuilds, 
so that people don't need to waste time with userland when rebuilding modules 
after kernel update.

Also, I'd really like to have nvidia-glx split from nvidia-kernel because of 
fbsd support, adding all on one ebuild would make it difficult to handle the 
fbsd case...

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Unified nVidia Driver Ebuild ready for testing

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Fri, Dec 23, 2005 at 09:49:04PM +0100, Diego 'Flameeyes' Pettenò wrote:
> I thought that we (gentoo devs) were trying to split the modules from ebuilds, 
> so that people don't need to waste time with userland when rebuilding modules 
> after kernel update.

We are. At least that's the policy suggested by the kernel herd. This
policy also allows applying securiy/bug fixes to kernel modules
without forcing users to recompile the userland part and vice versa.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

[gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Peter]

On Tue, 27 Dec 2005 16:50:16 +0100, Henrik Brix Andersen wrote:

> On Fri, Dec 23, 2005 at 09:49:04PM +0100, Diego 'Flameeyes' Pettenò wrote:
>> I thought that we (gentoo devs) were trying to split the modules from ebuilds, 
>> so that people don't need to waste time with userland when rebuilding modules 
>> after kernel update.
> 
> We are. At least that's the policy suggested by the kernel herd. This
> policy also allows applying securiy/bug fixes to kernel modules
> without forcing users to recompile the userland part and vice versa.
> 
> Regards,
> Brix

Thanks all for the feedback. It's important to realize that "userland" in
this case is under 1 minute compile time. One of the modules, glx, doesn't
even get compiled. A poster on this thread noted that glx took 14
seconds -- it just copies closed source libraries. Sometimes one can go
overboard trying to modularize and perfect an installation process. Look
at the user list and see how many problems some "enhancements" cause --
keyword changes, use variables, etc.!

Here, the intent is to simplify things, remove steps and ebuilds, and make
it more user friendly and require less interaction.



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

On Tuesday 27 December 2005 18:55, Peter wrote:
> Thanks all for the feedback. It's important to realize that "userland" in
> this case is under 1 minute compile time. One of the modules, glx, doesn't
> even get compiled. A poster on this thread noted that glx took 14
> seconds -- it just copies closed source libraries.
Here it takes a time variable between 30 seconds and 2 minutes depending on 
the load of the machine.
It's always things that gets copied, overwriting the extended attributes for 
pax (well I think pax counts only the executables, I'm wondering if paxctl 
would work on .so files, but I don't think so).

For sure, -xconfig and -settings are not going to be as simple to merge into 
the single ebuild for the paxctl thing above at least, not counting that many 
people (included me) don't really need -settings or -xconfig, and just use 
the default.

Current situation seems to me one of the most clean possible, way simpler than 
using nvidia's manual installation, and for what I've seen with users, it's 
not _so_ difficult to understand.

> Here, the intent is to simplify things, remove steps and ebuilds, and make
> it more user friendly and require less interaction.
I already said that FreeBSD and Linux modules have _nothing_ in common and 
merging all in one ebuild is going to give me an headache to fix it. I'm not 
going to drop the FreeBSD support tho.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[R Hill]

Peter wrote:
> To Gentoo nVidia users:
> 
> We are in the process of developing and testing
> a unified nVidia driver ebuild. When implemented,
> it will replace the nvidia-kernel, nvidia-glx, and 
> nvidia-settings ebuilds. It will also add the utility
> nvidia-xconfig.

Well I just wanted to say thanks for doing this.  It doesn't make sense to have
two different ebuilds (kernel & glx) for one package.  kernel & glx are
essentially tied together by version anyways.  nvidia-settings might be
arguable, as it's not too very small (~1MiB) and not necessary for basic usage
of the driver.

>From a new-driver-version perspective it makes sense, if not from the
new-kernel-version perspective.  But really, you're talking about a few extra
seconds to merge the glx portion (which doesn't need compiling), and it saves
you from unpacking the ~11MiB driver file twice.


--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unified nVidia Driver Ebuild ready for testing

[Paweł Madej]

Peter wrote:
> To Gentoo nVidia users:
> 
> We are in the process of developing and testing
> a unified nVidia driver ebuild. When implemented,
> it will replace the nvidia-kernel, nvidia-glx, and 
> nvidia-settings ebuilds. It will also add the utility
> nvidia-xconfig.
> 
> We would like your help in evaluating, testing, and
> commenting on this approach. Please locate the latest
> nvidia ebuild at: 
> 
> http://bugs.gentoo.org/show_bug.cgi?id=116085
> 
> The download package for the new ebuild is at:
> http://bugs.gentoo.org/attachment.cgi?id=75389
> 
> This is the very latest nVidia 8178 driver. Please
> be sure and review the nVidia changelog and readme.
> If your fonts are abnormally small, see Appendix Y
> and the nVidia forums for info on DPI. See
> 
> http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14
> 
> for specific news and info about the nVidia drivers
> for linux.
> 
> Since this is a developmental ebuild, it is NOT currently
> in portage. If you would like to try it out, please
> follow these simple instructions:
> 
> 1) Untar the file into /usr/local/portage/x11-drivers
> (if your portage overlay is in a different location,
> adjust accordingly).
> 
> 2) exit all window managers
> 
> 3) unmerge nvidia-kernel, nvidia-glx, and nvidia-settings
> (emerge -C .....) This ebuild will NOT install if any
> other nVidia ebuilds are installed.
> 
> 4) edit /etc/portage/package.keywords and add
> 
> x11-drivers/nvidia-drivers   ~x86 (or ~amd64). 
> Other arches are not supported. Sorry.
> 
> 5) emerge nvidia-drivers.
> 
> This will load the kernel module, glx support, nvidia-
> settings and -xconfig all in one swoop.
> 
> NOTE: Modular X support is not yet implemented.
> 
> If you have comments, notice a bug, or if you have 
> suggestions for improvement, PLEASE post to the existing
> bug report:
> 
> http://bugs.gentoo.org/show_bug.cgi?id=116085.
> 
> Please DO NOT report bugs about the upstream driver. If the
> driver does not work, then see the nVidia news forum.
> 
> We hope you will find this approach a more streamlined and
> easy implementation for nVidia.
> 
> Thanks for your participation and feedback.
> 
> Peter Hyman on behalf of the nVidia devs.
> 
> 
> 
In my opinion if you want to build monolitic ebuild in system like 
gentoo where everything is going to be modular you should try some local 
USE flags for example monolitic to install all the stuff you are puting 
into it and of cours flags for every part which could be istalled 
independly.

As a common user i need only nvidia-kernel and its dependency nvidia-glx 
to be happy.

Greets
Pawel Madej
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Peter]

On Wed, 28 Dec 2005 01:06:43 +0100, Pawe Madej wrote:

> In my opinion if you want to build monolitic ebuild in system like
> gentoo where everything is going to be modular you should try some local
> USE flags for example monolitic to install all the stuff you are puting
> into it and of cours flags for every part which could be istalled
> independly.
> 
> As a common user i need only nvidia-kernel and its dependency nvidia-glx
> to be happy.
> 
> Greets
> Pawel Madej

Thanks for your feedback from the user POV. You point out part of the
current problem. glx is NOT a dependency of kernel. So a user who installs
kernel will NOT get glx under the current situation. This will cause
nvidia to fail at startup.

This is because glx has kernel as a dependency. Can't have it both ways
(as someone else here pointed out) because you'd have a circular
dependency...kernel requires glx, but glx requires kernel which requires
glx...and around we go.

As for more USE flags? I would say not a good idea. There are too many of
them already. :)

As for modularity, there comes a time when this goes to an extreme. Adding
closed source libraries (glx) to install along with the kernel source adds
no overhead (one user said 14 seconds to install glx) and provides a
complete solution without compromising any other part of any other
kernel's installation. So users who update a kernel won't be harmed and
everything can coexist. Unmerge will uninstall from the current kernel
path.

I _do_ see the argument that including the extra applications could be
spun off from the main package.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[fire-eyes]

> I _do_ see the argument that including the extra applications could be
> spun off from the main package.

I would appreciate nvidia-settings remaining stand alone, due to this as
of yet unresolved bug:

http://bugs.gentoo.org/show_bug.cgi?id=114649
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Chris Gianelloni]

On Wed, 2005-12-28 at 13:40 -0500, Peter wrote:
> This is because glx has kernel as a dependency. Can't have it both ways
> (as someone else here pointed out) because you'd have a circular
> dependency...kernel requires glx, but glx requires kernel which requires
> glx...and around we go.

Why can't both RDEPEND on the other?  This works perfectly fine for many
packages in the tree.  A circular dependency isn't a bad thing if
they're both in RDEPEND, it is when they're both in DEPEND that causes
an issue.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Fri, 30 Dec 2005 12:54:21 -0500 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| On Wed, 2005-12-28 at 13:40 -0500, Peter wrote:
| > This is because glx has kernel as a dependency. Can't have it both
| > ways (as someone else here pointed out) because you'd have a
| > circular dependency...kernel requires glx, but glx requires kernel
| > which requires glx...and around we go.
| 
| Why can't both RDEPEND on the other?  This works perfectly fine for
| many packages in the tree.  A circular dependency isn't a bad thing if
| they're both in RDEPEND, it is when they're both in DEPEND that causes
| an issue.

It only works right now because of a coincidence in how Portage's dep
resolver (doesn't) work.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Tres Melton]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Sun, 2006-01-01 at 01:12 +0000, Ciaran McCreesh wrote:
> On Fri, 30 Dec 2005 12:54:21 -0500 Chris Gianelloni
> <wolf31o2@gentoo.org> wrote:
> | On Wed, 2005-12-28 at 13:40 -0500, Peter wrote:
> | > This is because glx has kernel as a dependency. Can't have it both
> | > ways (as someone else here pointed out) because you'd have a
> | > circular dependency...kernel requires glx, but glx requires kernel
> | > which requires glx...and around we go.
> | 
> | Why can't both RDEPEND on the other?  This works perfectly fine for
> | many packages in the tree.  A circular dependency isn't a bad thing if
> | they're both in RDEPEND, it is when they're both in DEPEND that causes
> | an issue.
> 
> It only works right now because of a coincidence in how Portage's dep
> resolver (doesn't) work.
> 
Isn't this what PDEPEND is for?
-- 
Tres Melton
IRC & Gentoo: RiverRat

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]