libtool: link: `/usr/lib/libdbus-1.la' is not a valid libtool archive make[4]: *** [libmetacity-private.la] Error 1 dbus is 1.4.0 Reproducible: Always emerge --info --- Unmatch removal atom(s) in /var/lib/layman/java-overlay/profiles/package.mask: -=dev-java/sun-jdk-1.5* Portage 2.2_rc84 (default/linux/powerpc/ppc32/10.0/desktop, gcc-4.4.4, glibc-2.12.1-r1, 2.6.33-gentoo-r1-l0 ppc) ================================================================= System uname: Linux-2.6.33-gentoo-r1-l0-ppc-7447A,_altivec_supported-with-gentoo-2.0.1 Timestamp of tree: Sun, 19 Sep 2010 09:00:20 +0000 distcc 3.1 powerpc-unknown-linux-gnu [disabled] ccache version 2.4 [enabled] app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.5.4-r4, 2.6.5-r3, 3.1.2-r4 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.3 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13::<unknown repository>, 2.67 sys-devel/automake: 1.6.3::<unknown repository>, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.2.4-r1, 4.3.5, 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="ppc ~ppc" ACCEPT_LICENSE="* -@EULA IBM-J1.5 IBM-J1.6" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-mcpu=7400 -O2 -pipe -fno-strict-aliasing -maltivec -mabi=altivec" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-mcpu=7400 -O2 -pipe -fno-strict-aliasing -maltivec -mabi=altivec" DISTDIR="/in_n_outs/distfiles" FEATURES="assume-digests ccache distlocks fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.uni-c.dk/pub/gentoo/ ftp://trumpetti.atm.tut.fi/gentoo/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://mirror.switch.ch/mirror/gentoo/ ftp://ftp.heanet.ie/pub/gentoo/ ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo http://mirror.gentoo.no/ " LANG="C" LC_ALL="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="fr fr_FR" MAKEOPTS="-j2" PKGDIR="/in_n_outs/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/java-overlay /var/lib/layman/kde-sunset /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d a52 aac acl alsa altivec apache2 berkdb bluetooth branding bzip2 cairo cdr cli consolekit cracklib crypt cscope cups cxx dba dbus dri dts dvd dvdr emboss encode exif fam fbcon filter flac flash fortran gb gcj gd gdbm gif gnome gpm gtk gtk2 hal iconv ipv6 java jikes jpeg kde kdehiddenvisibility kpathsea lcms ldap libnotify mad mikmod mng modules mozdevelop mozsvg mp3 mp4 mpeg mudflap ncurses nls nptl nptlonly nsplugin objc ogg oggvorbis opengl openmp pam pango pcre pdf pdflib perl png povray ppc ppds pppd python qt qt3support qt4 readline reflection samba sasl scanner sdl session speex spell ssl startup-notification svg sysfs tcpd tetex theora threads tiff tk truetype udev unicode usb vorbis wmf xcb xine xinerama xml xml2 xorg xosd xulrunner xv xvid zlib" ALSA_CARDS="snd-aoa" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon" ELIBC="glibc" INPUT_DEVICES="keyboard mouse wacom evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="fr fr_FR" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="ati fbdev radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
.la file problems? # emerge lafilefixer # lafilefixer --justfixit or good old # revdep-rebuild
*** Bug 338323 has been marked as a duplicate of this bug. ***
*** Bug 338331 has been marked as a duplicate of this bug. ***
/usr/lib64/libdbus-1.la does not exist, it seems ebuild did not compile it or did not install it.
(In reply to comment #4) > /usr/lib64/libdbus-1.la does not exist, it seems ebuild did not compile it or > did not install it. > dbus-1.4.0 ebuild has such a problem.
running revdep-rebuild fixed it for me
reopening to assign to correct herd
It seems the dev that bumped dbus to 1.4 dropped the la file on purpose. To fix it, just run lafilefixer and it'll save your day.
Maybe an elog message should be added to dbus ebuild suggesting to run lafilefixer, as looks like some people doesn't run it usually
(In reply to comment #9) > Maybe an elog message should be added to dbus ebuild suggesting to run > lafilefixer, as looks like some people doesn't run it usually > no, i'm opposed to cluttering every second ebuild with library with such elog just like i'm opposed to writing elog about every second library with ABI bump that needs revdep-rebuild run but if you want to write a Portage News message instead of disappearing .la for every user, so he can just acknowledge and delete the message then, that'd be fine... reviews on dev ML as usual
I heard Zac Medico implemented lafilefixer functionality within portage, I'm not sure however what version is this.
masked versions of portage for the moment afaik.
Created attachment 248346 [details] lafilefixer --justfixit log lafilefixer --justfixit does not fix the proble of Missing libdbus-1.la
The manual way, without lafilefixer: You can use something like, find /usr/lib -name '*.la' -exec grep libdbus-1 '{}' + and same for /usr/local and other dirs, perhaps whole /usr to find the broken .la files. Just get rid of them, or re-emerge the packages they belong to, either way is fine
metacity and pulseaudio compliled after running lafilefixer --justfixit, though /usr/lib/libdbus-1.la is still missing, it is not a problem any more.
*** Bug 338668 has been marked as a duplicate of this bug. ***
Other D-Bus maintainers disagree with this pain caused to users. Requiring lafilefixer --justfixit all the time (as in, every upgrade bringing some other package that needs it) is completely unjustified. Make a global plan and don't cause constant pain to users.
nah
I don't see much problem on running "lafilefixer --justfixit" after updating (I already do it always after updating my system). Also, probably lafilefixer won't be needed in the future when portage-2.1.9 hits stable and people re-emerge their systems (since, if I don't misremember, that portage version fixes la files automatically)
People wouldn't be filing bugs if this were painless and without any problems...
I think that it's because either an elog message or a news file should suggest people to run it :-/
And that's the problem. People are killing the .la files from many packages over time, so you'd have to elog it for many things all the time, and users having to run this stuff all the time for no particular good reason (the .la files staying there don't bother most people I claim). So now we have a few individual developers killing .la files one by one over an extended time period, causing constant gradual pain to users, instead of making a global plan and dealing with the .la files in one swoop, making users only once to worry about it instead of all the time like now.
you can also note that said developers don't even pay attention to rules that would allow mostly seamless death of said la files (for example, reading flameeyes' blog on the subject). Sure it requires more time this way but that's the price to pay if we don't want to constantly inflict this kind of problem on our userbase.
As such, reopening and CCing QA for their opinion. We are getting bugs filed about these issues on every occasion, this time dbus, before other packages, and so on. I obviously expect Samuli to not act on QA's behalf on this.
Please introduce an news item about that. Sooner or later portage will drop every useless la files and this lead to many compilation errors, like this one. News item is a great feature so I guess we should use it. imho, qa + portage people should take care of this news item
@QA, Mart (for Gnome) and I (for x11) have been discussing .la files removal for quite some time now, and we *want* to do it. But we've both agreed that we wanted to do it in a *synchronized* manner. Please let's get together and talk it over. Let's come up with a proper *plan* instead of doing one package here and there. Cheers
(In reply to comment #26) > @QA, > > Mart (for Gnome) and I (for x11) have been discussing .la files removal for > quite some time now, and we *want* to do it. But we've both agreed that we > wanted to do it in a *synchronized* manner. > > Please let's get together and talk it over. Let's come up with a proper *plan* > instead of doing one package here and there. That sounds great. I'd like this to be done in a way that makes it so it "Just Works" for our users. Lets move the discussion and planning to a mailing list or the aliases if you prefer that. Bugzilla isn't exactly the forum for having a lengthy discussion.
So, Mart and Remi just volunteered to start with the basic idea of clearing up these? http://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&emailassigned_to1=1&emailtype2=substring&emailreporter2=1&bugidtype=include&chfieldto=Now&short_desc=pointless+libtool+archive&short_desc_type=substring&long_desc_type=substring&bug_file_loc_type=substring&status_whiteboard_type=substring&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&cmdtype=doit&order=Reuse+same+sort+as+last+time&sourceid=Mozilla-search so I'll resume filing them, or should we wait another four years of planning like it happened with --as-needed? Do I have to remember that it's totally seamless to users to remove .la files from _new_ packages, yet it seems to me not everybody seem to do that at all?
We have nothing against properly removed .la files according to your old blog posts. The issue is removal of .la files on version bumps when it's still the same ABI. I believe those should be volunteering for the global work and its planning who are so inclined to get them gone to break it badly for users for every upgrades without a global plan. I'm not the one who is causing pain to users, why should I need to find the time for this to save users pain, if it works fine without any .la removal too (for same ABI - I fully agree that there's no need for .la files for new packages or on ABI breaks or modules).
Yah yah yah "it does not cause pain to users" forgets the "unless they are forced to rebuild half their system after any one package changed ABI, like it happened with libpng". The list I posted has a number of gnome-assigned bugs for files that could very well just be deleted because _they are never linked against and thus never listed in other .la files_, yet months after filing they haven't even been looked at. Is that how you plan to tackle it? Put your feet down "no we won't do anything until we have a plan"? You've been talking about planning it for the past two or three years, have you come up with anything at all? BTW if I'm not mistaken Portage 2.1.9 also integrates lafilefixer stuff, so ~arch should be fine.
(In reply to comment #28) > So, Mart and Remi just volunteered to start with the basic idea of clearing up > these? > > so I'll resume filing them, or should we wait another four years of planning > like it happened with --as-needed? You'll notice that 4 bugs in those list are from the x11 and gnome herd. Let me add that I haven't moved on the x11 bug for only *one* reason: I want to do all X11 packages in one go, in the eclass. Upstream Xorg supports static building *only* through pkg-config, so .la files are completely unsupported as far as they're concerned. I *want* to clean them up. > Do I have to remember that it's totally seamless to users to remove .la files > from _new_ packages, yet it seems to me not everybody seem to do that at all? Both Gnome and X11 packages aren't exactly new, I'm sure you'll agree on this :) Cheers
Are you freaking kidding me? Those are mostly Python bindings and that stuff you don't do "on eclass level" for either x11 or gnome, it's _already_ done on eclass level with Python... And where it's not just the .la to be extra, because .a is compiled, you have to fix it UPSTREAM by adding -shared to the LDFLAGS. Do me a favour, check the bugs again, check my posts on the matter, get a clue about .la files, then tell me what is your plan. And don't tell me _I_ have to come up with a plan, because my plan is pretty simple: get all of them destroyed one by one as soon as I can. You don't like it? COME UP WITH SOMETHING BETTER, rather than insisting that "you want to do so with a plan" that is never coming.
(In reply to comment #30) > Yah yah yah "it does not cause pain to users" forgets the "unless they are > forced to rebuild half their system after any one package changed ABI, like it > happened with libpng". I'm not sure what this is about. libpng broke ABI, so it is an upstream caused pain, and removing .la files at the same time as introducing the ABI break version sounds fine and was probably done. This bug is not about libpng .la file removal, this is about dbus and other such situations, which did not break ABI at all. > The list I posted has a number of gnome-assigned bugs for files that could very > well just be deleted because _they are never linked against and thus never > listed in other .la files_, yet months after filing they haven't even been > looked at. This bug has nothing to do with those bugs your bugzilla link shows. Lets not confuse two completely different things here. We are talking about cases where removal causes user pain, not cases where removal of them does not have any affect, because, as you say, they are never linked against and never referenced in other .la files. > Is that how you plan to tackle it? Put your feet down "no we won't do anything > until we have a plan"? We have nothing against fixing the bugs you referenced regarding plugins installing .la files and so on. Those bugs simply are not of high priority, as simple as that, and they haven't all been dealt with due to manpower and much more important real bugs having to be fixed. Some gnome maintainers actively remove .la files safely (plugin .la files) when they notice. As nothing links to them, there's no problems caused by the .la files afterall, they just take an inode and 4KB of disk space. > You've been talking about planning it for the past two or three years, have you > come up with anything at all? I don't appreciate this tone. I don't get paid to do Gentoo work. I do however care for our users regardless.
(In reply to comment #32) > Are you freaking kidding me? > > Those are mostly Python bindings and that stuff you don't do "on eclass level" > for either x11 or gnome, it's _already_ done on eclass level with Python... And > where it's not just the .la to be extra, because .a is compiled, you have to > fix it UPSTREAM by adding -shared to the LDFLAGS. > > Do me a favour, check the bugs again, check my posts on the matter, get a clue > about .la files, then tell me what is your plan. And don't tell me _I_ have to > come up with a plan, because my plan is pretty simple: get all of them > destroyed one by one as soon as I can. > > You don't like it? COME UP WITH SOMETHING BETTER, rather than insisting that > "you want to do so with a plan" that is never coming. First, PIPE DOWN! What's your problem?!!!!! I'm not yelling at you, I'm not angry at anyone, I'm just talking! I've never implied you or anyone else come up with a plan, I just want to sync with other teams if I'm to remove .la files from all my packages, THAT'S ALL! Second, xpyb is one lone package hardly ever used. libX11, cairo, gtk+, those are the ones that are bothering me. Diego, I have no idea what's wrong with you today, but please get a hold of yourself and grow up. Cheers (because I'm not currently angry at anyone, let me say it again)
Neither the rest of us are paid. But if I'm not paid to do something, but I have an opinion, the time, and the will to do something about it, and you disagree, have no time or will to come up with an alternative, you cannot just drag your feet and expect ME to stop doing my work, given that it's actually trying to save users trouble in the future (which we have had an example of already), if your only concern is that "you want to do it on your terms".
needless to say, the removal of .la files will continue as is, but if you want to plan while at it or write a news item, go ahead no reason for this bug to be kept open anymore, needless to say also the libdbus-1.la is gone already and won't be restored continue with your plans on -dev ML, meanwhile Xfce4 team decided to kill all the .la files in one swoop at xfconf.eclass, and went painless. did that the same day --as-needed became the new default.
So, should we conclude that QA is ok with devs removing la files even for heavily used libraries without a word to anyone, especially users ? gnome team took great care (maybe too much for some people) of removing la files when it didn't cause any pain, but seeing how the issue is handled, it feels like it was a waste of time.
I think most of QA agrees that the remaining inconvenience in .la files removal is acceptable for ~arch as it is; we have a Portage releases that worksaround .la files by itself to begin with and there aren't so many systemic users of them in the system with the exception of, well, X11 and GNOME. I spoke with Remi earlier tonight, and I think we agree that it would be the right time now to switch both X11 and GNOME to drop them, together, since the two are the only one remaining interwinded. Of the three major environments using X11, KDE does no longer use .la files at all (since they don't use libtool); XFCE is already migrated to no .la files, so GNOME is the only one remaining. Picking the -lX11 references in the tinderbox, there are 891 .la file referencing it, which would make it scary if it wasn't that more than half of them are plugin files (which is why I stressed the need to _drop the .la files from plugins as fast as possible_ to actually have an acceptable assessment, but it was too much work to ask for, I guess) a lot of which are actually GNOME's. After filtering it down, although not completely, I came down to 441 files in 226 packages, once again more than of which are X11 or GNOME. At least part of those are actually used by .la files of internal libraries, not publicly accessible libraries, which means that they don't really need to be there in the first place, but once again, it seems like my chart [1] didn't provide enough clues to most people. I'll venture a guess that, for libX11, no more than 50 packages will actually have .la files that will cause further builds to stop working until running lafilefixer, revdep-rebuild, or the maintainer drops those .la files as well. You know how it goes with bandaids and hairs? It causes much much more pain to take them off slowly, so do it quickly.. which doesn't mean "wait forever until not even a single hair gets pulled"… let's solve it once and for all and get rid of X11/GNOME's .la files, the rest will have to follow suit, and users won't hit nastier problems as it happened with libpng14. P.S.: I'm quite sure we have had much more reports regarding builds stopping due to the libpng14 upgrade than we ever had regarding .la files; what's worse, then? Risking another libpng14-like fallout (which in turn wasn't much different from the libexpat fallout) or causing a couple more rebuilds to users in the interim while moving on? [1] http://blog.flameeyes.eu/files/la-removal-flowchart.png
FTR, if I change the xorg-2 eclass, this *will* affect stable users as well. I just wanted to mention that bit of information :) Cheers
I've reverted the original commit which removed the .la files on behalf of the maintainer Steev. Reopening to close with proper status
Fixed with: Using commit message: ------------------------------------------------------------------------------ Revert: 'remove .la files' and 'Remove USE conditional for removing .la files' on behalf of steev and revbump so users get the change. Contact steev if you have issues with or questions about this commit. (Portage version: 2.1.9.10/cvs/Linux x86_64) ------------------------------------------------------------------------------
Meh, so we're going to endlessly postpone .la crap removal? It's ~arch version of dbus that has those files removed so I think it was fair to leave ~arch 'broken' in this case. ~arch is "testing" after all.
(In reply to comment #42) > Meh, so we're going to endlessly postpone .la crap removal? It's ~arch version > of dbus that has those files removed so I think it was fair to leave ~arch > 'broken' in this case. ~arch is "testing" after all. > I've had to revert it... it was technically wrong.
For once I totally agree with reavertm here. We've been postponing the removal for well over three years now. And each time there is a change that changes those, requires users to go through "a little" pain.
Well it seems there is a disagreement on then necessity to inflict this little pain now (considering it's bigger than for some not so commonly used library). Since there is already a handful of developers on each side, maybe it's time to turn to council ?
After taking a breather, this is actually the correct path. DBus 1.4 is an unstable aka ~arch package, and a good spot to remove the .la file. People running ~arch should expect at least some growing pains as it is not stable. The commit will not be reverted again, however if it were stable, I would be reverting the change. This will probably cause issues with stable systems, so will require extensive testing (perhaps the tinderbox Flameeyes? *bats lashes*) before it can go stable.
(In reply to comment #46) > reverting the change. This will probably cause issues with stable systems, so > will require extensive testing (perhaps the tinderbox Flameeyes? *bats lashes*) > before it can go stable. What kind of issues are you talking about? For some users, there will be pollution of .la files from libdbus-1.la, you can't avoid that. It will be quite minimal, if the user has world built with LDFLAGS="-Wl,--as-needed" but still doesn't cover all. That's why I said what I said in Comment #10 right from the start, before all the unnecessary drama. Users have not been informed of `emerge lafilefixer` and `lafilefixer --justfixit` in a centralized location, Portage News, yet. That is, if you even consider this to be a problem. I'd categorize it as a minor annoyance where as some people are screaming of some "major breakage". What a breakage, you need to run one script to fix bunch of broken text files which don't effect the running system at all. At most, it will give you a bit of headacke trying to figure correct order to emerge packages (that is, if you are not aware of lafilefixer yet). Something Google will give answer right away, Gentoo Forums too, as well as IRC. I'd say even bug-wranglers should be available to direct users to forums for help and mention lafilefixer on the way out. This whole thing is being blown out of porpotion. So if you push all this, imho, nonsense a side, the 1.4.0 is relatively trivial version bump over 1.2.24.
May I restate the divergence here: we all agree that removing la files is a good thing. The problem is where to remove it first. Removing it from "core" library doesn't seem wise, especially since next kde stablization will require dbus 1.4 as far as we've been told. We agree it's no big deal for ~arch users, but if this release of dbus goes stable, we will inflict the same pain ~arch users are experiencing on _stable_ users. A new item would be a good thing to do, but we should prepare it now. Finally I still think it would be simpler and a lot less bumpier road to remove la files from leaf packages first like flameeyes suggested in his blog months ago.
*** Bug 339061 has been marked as a duplicate of this bug. ***
(In reply to comment #48) > we all agree that removing la files is a good thing. The problem is where to > remove it first. Removing it from "core" library doesn't seem wise, especially > since next kde stablization will require dbus 1.4 as far as we've been told. (In reply to comment #38) > I spoke with Remi earlier tonight, and I think we agree that it would be the > right time now to switch both X11 and GNOME to drop them, together, since the > two are the only one remaining interwinded. Of the three major environments > using X11, KDE does no longer use .la files at all (since they don't use > libtool); XFCE is already migrated to no .la files, so GNOME is the only one > remaining. Gilles, as Diego pointed out, KDE-4.X is no longer affected by the .la files as it relies on cmake and doesn't use libtool. KDE-3.5 users will be affected, but it was moved to the kde-sunset overlay for a reason and any user still running it is responsible for it.
(In reply to comment #47) > (In reply to comment #46) > > reverting the change. This will probably cause issues with stable systems, so > > will require extensive testing (perhaps the tinderbox Flameeyes? *bats lashes*) > > before it can go stable. > > What kind of issues are you talking about? > > For some users, there will be pollution of .la files from libdbus-1.la, you > can't avoid that. It will be quite minimal, if the user has world built with > LDFLAGS="-Wl,--as-needed" but still doesn't cover all. For a while now, --as-needed has been the default, it does not fix la files being missing. > That's why I said what I said in Comment #10 right from the start, before all > the unnecessary drama. Users have not been informed of `emerge lafilefixer` and > `lafilefixer --justfixit` in a centralized location, Portage News, yet. > > That is, if you even consider this to be a problem. > > I'd categorize it as a minor annoyance where as some people are screaming of > some "major breakage". What a breakage, you need to run one script to fix > bunch of broken text files which don't effect the running system at all. > > At most, it will give you a bit of headacke trying to figure correct order to > emerge packages (that is, if you are not aware of lafilefixer yet). Something > Google will give answer right away, Gentoo Forums too, as well as IRC. > I'd say even bug-wranglers should be available to direct users to forums for > help and mention lafilefixer on the way out. > > This whole thing is being blown out of porpotion. Sorry you feel like being able to run a little script gives you free reign to run willy nilly over the stable tree and break packages. It isn't that you removed la files, it is that you removed them from stable packages, and gave a lame excuse for doing so. > So if you push all this, imho, nonsense a side, the 1.4.0 is relatively trivial > version bump over 1.2.24. > Which is what my post was even about, if you'd have taken 2 seconds to pull your head out of your ass. Relatively trivial bump for ~arch users.
(In reply to comment #50) > as Diego pointed out, KDE-4.X is no longer affected by the .la files as it > relies on cmake and doesn't use libtool. KDE-3.5 users will be affected, but it > was moved to the kde-sunset overlay for a reason and any user still running it > is responsible for it. I didn't say kde itself will be a problem, I said, if kde wants to go stable and dbus 1.4 has to go with it, it'll still break all other packages that still provide the la files.
For the record, next stable KDE version will be in 4.6 series, which means next year
Is it possible to bring gnome without .la files into stable before dbus-1.4 goes stable? If yes this is a clear way to avoid problems for stable users...
(In reply to comment #54) > Is it possible to bring gnome without .la files into stable before dbus-1.4 > goes stable? If yes this is a clear way to avoid problems for stable users... > 2.30 is our latest stable and gnome 2.32 is released today. If we want to bring a pain free experience we will have to raise dependencies on packages that don't install la files from the start, which is not how we currently deal with dependencies. Other solution would to sync with x11 herd and have a switch in the eclass that would do this for us. Problem are: * we are not the only users of our eclass and can't tell who will still want static libs and la files, ... * it would affect stable users * we need a news item for the D day (not a big problem, just a note to self) and there's probably more reasons that make this not so easy to do this in say 30 days.
If I understood you correctly main pain are applications that use gnome2 eclass - they do not allow you to add magic find-remove-la files into eclass. Right? What if you add this magic line and will require application to define some REMOVE_LA=yes variables in all gnome 2.32 packages?... And I'm not sure I understood what you told about dependencies...
If "lafilefixer --justfixit" is a fix, which worked for me after reading this, PLEASE just add a dependency to lafilefixer to dbus-1.4, now "stable", and "lafilefixer --justfixit" to dbus-1.4 pkg_postinst. Otherwise this will just keep breaking for everyone who's not one of the Gentoo devs.
Ping!
