Howdy guys,
please review the attached file and suggest updates to in.
I was asked for this thing going stable due to its being dependency of
new nvidia-drivers.

Also this thing is probably blocker for the bug on eselect-opengl i just
opened:
http://bugs.gentoo.org/show_bug.cgi?id=301271

Cheers

--------
Tomáš Chvátal
Gentoo Linux Developer [KDE/Overlays/QA/X11]
E-Mail : scarabeus@gentoo.org
GnuPG FP : 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587
GnuPG ID : 03414587
Title: Removal of libGL.la
Author: Tomáš Chvátal <scarabeus@gentoo.org>
Content-Type: text/plain
Posted: 2010-01-20
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <app-admin/eselect-opengl-1.1.1-r2

Eselect-opengl package now strips the libGL.la file. This file was broken and
thus we proceeded with its removal. It brings slight inconvenience on you fellow
users. After emerging the new version =app-admin/eselect-opengl-1.1.1-r2 please
emerge one more package dev-util/lafilefixer and use it for fixing all various
compilation issues by running as root:
# lafilefixer --just-fixit
Note that not-running this command will bring you compilation issues so you
should really pay attention to this message and act upon it.

On 1/17/10 12:26 PM, Tomáš Chvátal wrote:
> please review the attached file and suggest updates to in.
> I was asked for this thing going stable due to its being dependency of
> new nvidia-drivers.

I wonder why the affected package (eselect-opengl) couldn't run
lafilefixer itself. It's mandatory for all users, and would save a lot
of frustration.

And I think we're doing something similar with gcc (fix_libtool_files.sh
seems to run automatically on gcc upgrade). Earlier it wasn't automatic,
and it was a bit of pain (a lot more for inexperienced users, needlessly).

Long story short: if something must be done and system can do it
automatically and perfectly, why should we require the user to do it
manually?

Additional benefit: less bugs reported (I'm sure some people are going
to miss the announcement, or read it without understanding).

Paweł Hajdan jr

On 01/17/2010 01:26 PM, Tomáš Chvátal wrote:
> Howdy guys,
> please review the attached file and suggest updates to in.
> I was asked for this thing going stable due to its being dependency of
> new nvidia-drivers.
>
> Also this thing is probably blocker for the bug on eselect-opengl i just
> opened:
> http://bugs.gentoo.org/show_bug.cgi?id=301271
>
> Cheers
>
> --------
> Tomáš Chvátal
> Gentoo Linux Developer [KDE/Overlays/QA/X11]
> E-Mail : scarabeus@gentoo.org
> GnuPG FP : 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587
> GnuPG ID : 03414587

Instead of the gentoo-pr mailing list you are supposed to send news
items to pr@gentoo.org. I cced so that they get it as fast as possible.

Regards,
Petteri

On Sun, 17 Jan 2010, "Paweł Hajdan, Jr." wrote:

> I wonder why the affected package (eselect-opengl) couldn't run
> lafilefixer itself. It's mandatory for all users, and would save a lot
> of frustration.

It is not mandatory: You could as well re-emerge the affected packages
(shown by revdep-rebuild) which is a much cleaner solution, since it
does not break the portage database like lafilefixer does.
(Yes, I know that this might involve manual fixing the order shown
by revdep-rebuild or emerging packages twice or packages not listed,
but it *is* possible to do it cleanly).

> And I think we're doing something similar with gcc (fix_libtool_files.sh
> seems to run automatically on gcc upgrade).

Yes, this is terrible: I actually considered filing a bug about it,
requesting to make it at least only optional.

Please: When you run tools which break checksums/dates of the database,
give the user the possibility to decide whether he really wants this.
For instance, USE="+lafilefixer" might be such an option.

Martin

On 1/17/10 6:57 PM, Vaeth wrote:
> On Sun, 17 Jan 2010, "Paweł Hajdan, Jr." wrote:
>> I wonder why the affected package (eselect-opengl) couldn't run
>> lafilefixer itself. It's mandatory for all users, and would save a lot
>> of frustration.
> It is not mandatory: You could as well re-emerge the affected packages
> (shown by revdep-rebuild) which is a much cleaner solution, since it
> does not break the portage database like lafilefixer does.

I see. To be more precise, I meant "something must be done to have a
not-broken system".

> Please: When you run tools which break checksums/dates of the database,
> give the user the possibility to decide whether he really wants this.

Good point, I didn't realize that. However, I'd rather fix the tool (for
example to update the portage database).

Paweł Hajdan jr

On 01/17/10 18:20, "Paweł Hajdan, Jr." wrote:
>> Please: When you run tools which break checksums/dates of the database,
>> give the user the possibility to decide whether he really wants this.
>
> Good point, I didn't realize that. However, I'd rather fix the tool (for
> example to update the portage database).

Nope, that's a bad idea unless you plan to implement such feature for portage,
paludis and pkgcore (and possibly other package managers).

So use revdep-rebuild (longer but correct solution) or lafilefixer (quicker but
introduces other problems).

--
Krzysiek Pawlik <nelchael at gentoo.org> key id: 0xBC555551
desktop-misc, java, apache, ppc, vim, kernel, python...

On 1/17/10 7:28 PM, Krzysiek Pawlik wrote:
> On 01/17/10 18:20, "Paweł Hajdan, Jr." wrote:
>>> Please: When you run tools which break checksums/dates of the database,
>>> give the user the possibility to decide whether he really wants this.
>> Good point, I didn't realize that. However, I'd rather fix the tool (for
>> example to update the portage database).
> Nope, that's a bad idea unless you plan to implement such feature for portage,
> paludis and pkgcore (and possibly other package managers).
> So use revdep-rebuild (longer but correct solution) or lafilefixer (quicker but
> introduces other problems).

Hmm... last time I tried revdep-rebuild for that problem it either
didn't notice something was wrong, or couldn't finish without manual
assistance.

How about fixing lafilefixer in an other way: it knows which .la files
are broken. Instead of changing their contents, it can re-emerge the
packages they belong to. But then it probably can't be run automatically
by the ebuild (nested emerges).

On the other hand, I really wonder how useful the checksums in portage
db really are. It includes config files which are frequently modified.
It also doesn't include config files the administrator has to create. So
for example for verifying system integrity is seems useless to me.

I'd expect only a limited group of users caring about the checksum
database, and the majority of affected users caring about the update to
"just work" (which running lafilefixer --just-fixit automatically would
buy us).

Paweł Hajdan jr

> >>> Please: When you run tools which break checksums/dates of the database,
> >>> give the user the possibility to decide whether he really wants this.
> >> Good point, I didn't realize that. However, I'd rather fix the tool (for
> >> example to update the portage database).

> On the other hand, I really wonder how useful the checksums in portage
> db really are. It includes config files which are frequently modified.
> It also doesn't include config files the administrator has to create. So
> for example for verifying system integrity is seems useless to me.
>
> I'd expect only a limited group of users caring about the checksum
> database, and the majority of affected users caring about the update to
> "just work" (which running lafilefixer --just-fixit automatically would
> buy us).

http://trac.mcs.anl.gov/projects/bcfg2/wiki/Gentoo

Section "Package Verification Issues" contains one example of why checksums should be
consistent.

Le 17/01/2010 12:26, Tomáš Chvátal a écrit :
> Howdy guys,
> please review the attached file and suggest updates to in.
> I was asked for this thing going stable due to its being dependency of
> new nvidia-drivers.
>
> Also this thing is probably blocker for the bug on eselect-opengl i just
> opened:
> http://bugs.gentoo.org/show_bug.cgi?id=301271

I'm not a big fan of the wording but it's something we refine, the
general idea is fine though.

I'll try to come up with something soon. If not, it can still be posted
as-is, it gets the point across.

Cheers,

Rémi

Le dimanche 17 janvier 2010 Ã* 13:37 +0100, Ben de Groot a écrit :
> 2010/1/17 "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org>:
> > I wonder why the affected package (eselect-opengl) couldn't run
> > lafilefixer itself. It's mandatory for all users, and would save a lot
> > of frustration.
>
> Indeed. You can simply have this version of eselect-opengl depend on
> lafilefixer and run it in pkg_postinst.
>
> Cheers,

Please do not lafilefixer without restricting the scope of the changes
it does to libGL.la specifically. It changes md5sum of installed files
(which then does not match what is recorded by portage at install), it
will also potentially hide bugs from packages dropping la files without
a word (and this is bad pratice/communication too which should get
reported).

--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo