I'll keep fixing bugs on my machine, using a local overlay and try to keep up. But neither does this solve the problem for others, ...

Be sure to keep filing bugs, though - if I encounter a problem, bugzilla is the first place I check, and it helps if someone already found a way to fix it

(Furthermore, each additional "Thanks that worked for me!" generally increases the chance of the fix being accepted)_________________“And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010

What I find strange, obviously (the officially supported) portage is too big for the amount of staff we've got, but neither do we really slim down portage, nor is there an easy process to get more staff responsible for that. I have no clue how many people are working on FreeBSD's ports, but last time I checked, they had more ports than we have and most times even are closer to upstream then we are.

I also have no clue, how many of their ports need specific treating in regards to the BSD-specs, but I'd guess that most userland packages don't need that much work - if at all - so maybe it would be possible to "whip up" a ports->portage converter._________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Last edited by avx on Sat Aug 20, 2011 8:38 pm; edited 1 time in total

Oh man, this thread is so full of righteous anger and so devoid of understanding.

Cyker wrote:

When I first moved from Slackware to Gentoo oh so many years ago, it was because I was attracted by the idea of a package management system which allowed *ME* to pick which features I wanted on the system, and which ones I didn't...

Some of those 97 are due to asinine package reorganizations (e.g. Samba splits changing AGAIN, all these new 'virtuals' etc.

OK, so the purpose of virtuals is to offer flexibility, to you, the user. It allows you to chose whether you want libav of ffmpeg, for instance. They also install literally nothing on your system (except for /var/db/pkg).

Without knowing what other things you're actually talking about, it's impossible to make anything better. So often this complaint is usually something like the person is building dev-vcs/git[perl] without knowing why USE=perl is enabled or why they'd need it, and now git pulls in 30 perl packages.

Cyker wrote:

It's not just upstream; In the past I've been hit by ebuilds updated in place (i.e. no version change) which have had optional deps changed to hard deps because a bug was posted about something in another package breaking without that dep.

I'm sure this happens sometimes. But it's definitely rare. And if you take the times it does happen, it's definitely even more rare that it's done without some proper reasoning.

jdhore wrote:

I blame pkgconfig needing glib which is retardation, but unfortunately, that's the way things are. At least there is now a replacement for pkgconfig called pkgconf that is smaller and doesn't require glib, but it's not in Gentoo yet

The problem here is that pkgconfig used to include a bundled version of glib-1, but it's since been removed. Now, if you don't want pkgconfig on your system (how can you have a system without pkgconfig anyway?), you should notice that it's in DEPEND, not RDEPEND, so emerge --depclean will remove it and glib for you.

Gusar wrote:

XavierMiller wrote:

Ah I see: glib is not glibc

Yeah, but your comment still applies. So much stuff uses glib nowadays that it can't really be considered bloat anymore. Because instead of bits and pieces of it being duplicated in every app, they all use a central library. The only problem possibly are really, really constrained environments.

Thank you. I feel better knowing someone here understands.

gkmac wrote:

I would like to know why the ebuild for vice-2.3 suddenly requires a full blown texlive (LaTeX) installation; some 180Mb of tarballs to download.

I think you're the guy that messaged me on IRC recently about this. It looks to me like it's actually required now. I'd yell at upstream.

Oh man, this thread is so full of righteous anger and so devoid of understanding.

I'm not going to get into hostilities with you, but just to address one thing:

mattst88 wrote:

Cyker wrote:

When I first moved from Slackware to Gentoo oh so many years ago, it was because I was attracted by the idea of a package management system which allowed *ME* to pick which features I wanted on the system, and which ones I didn't...

Some of those 97 are due to asinine package reorganizations (e.g. Samba splits changing AGAIN, all these new 'virtuals' etc.

OK, so the purpose of virtuals is to offer flexibility, to you, the user. It allows you to chose whether you want libav of ffmpeg, for instance. They also install literally nothing on your system (except for /var/db/pkg).

Just to clarify, what I actually said was:

Quote:

Some of those 97 are due to asinine package reorganizations (e.g. Samba splits changing AGAIN, all these new 'virtuals' etc.), but many many more are due to existing packages having their dependencies changed in some way, which pulls in some new dependencies which weren't needed before, which then pull in more dependencies ad nauseum. And I'm not even covering the blockers!

i.e. I was *excluding*, for example, the virtual and samba splits, as they are not actually new dependencies, but just yet more contrived changes in the way portage organizes things. (As a side note, I can understand the virtuals kludge, but I don't understand the apparent samba split change every big version change; I know this is not something from upstream as if I build from source the procedure is not significantly different...)

But look, don't get mad - I'm just bringing attention to what I feel is an an undesirable trend in this distro. I'm not wailing on the devs specifically; I know it's a lot of thankless work keeping these things maintained. Just maintaining my local overlay consumes far more zots than I'd like!

This post was literally just a rant; I'm not expecting anything to happen because of it, but frankly if it makes just a few people consider whether a dependency is really needed or not rather than take the easy route of just adding it then I'd be happy...

Never needed prelink for WINE in years, but the one time I used prelink on a Fedora box, it killed the system... Meh, another ebuild I need to keep in shape for myself._________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

As gruff as he is, SpanKY/vapier generally tends to be a pretty reasonable guy. Find what his reasoning is._________________“And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010

Some of those 97 are due to asinine package reorganizations (e.g. Samba splits changing AGAIN, all these new 'virtuals' etc.), but many many more are due to existing packages having their dependencies changed in some way, which pulls in some new dependencies which weren't needed before, which then pull in more dependencies ad nauseum. And I'm not even covering the blockers!

i.e. I was *excluding*, for example, the virtual and samba splits, as they are not actually new dependencies, but just yet more contrived changes in the way portage organizes things. (As a side note, I can understand the virtuals kludge, but I don't understand the apparent samba split change every big version change; I know this is not something from upstream as if I build from source the procedure is not significantly different...)

Right, fair enough. I'm not familiar with the samba stuff. Samba has a ton of new dependencies or something? If you just want to mount samba shares, you might consider net-fs/mount-cifs. It's significantly smaller.

Also, it's easy to see the new packages being pulled in, but a lot of times you forget about the packages that are no longer needed on your system just waiting to be emerge --depclean'd. I feel sure that the number of packages is always growing, but at least it's not totally one-sided.

Just because no one noticed it for 6 years does not mean it was not broken. However, if upstream says it's optional, then it's a completely different story.

(Also, if no one replies to the closed bug after a while, open a new one)_________________“And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010

I guess it wants to warn about: "Using (enabling/disabling) prelink globally on a running system ...". well, I never used it. wrong way to go in my pov. only useful for special cases not being my desktop system.

as for the maintenance reason to enforce prelink is, that some programs under wine may fail strangely at runtime for that address pointer mangling. in return either unnecessary bugreports may pop up that waste the time and energy of the maintainers/bugwranglers where prelink would be the solution or the users may post somewhere that gentoo simply fails whereas all other distros do fine. both are things that are not acceptable for a maintainer. well, spanky may have other reasons. these would be mines.

so, in the end, for a single soul like you, prelink is nonsense, but for the general way impossible to put optional.
do you want to manage a list for programs under wine that need prelink? how do you want to communicate it to the user?

and I have seen similar things with openoffice/libreoffice.
hurray for USE="custom-cflags" to ignore bugreports with that enabled. just to mention one thing.

hmm, looks like there is a contradiction with some hardwired depedencies vs USE="custom-cflags". fun
I wonder if a USE="custom" could be introduced for some packages and their schizophrenic dependencies.
I would like to see a list with packages and its schizophrenic dependencies. though, with reasoning for each ... o well ...

do you want to manage a list for programs under wine that need prelink?

Nah.

Quote:

how do you want to communicate it to the user?

Uhm, AppDB? There are a lot of people, posting workarounds for pretty much any strange case, so it shouldn't be to hard for the WINE-devs to add a "needs prelink (y/n)" checkbox. Other than that, give the ebuilds some einfo "If your app fails, try with USE=prelink".

I see this as an upstream failure. Just because other distros take the easy way out, shouldn't mean Gentoo has to do it too. If I wouldn't want my system to behave/install like I want it to be, I could use SUSE._________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Seems app-emulation/vice is a strange package. On a manual build (./configure; make) sometimes it rans right through and sometimes it fails with the "no TeX"-error (updated above bug accordingly). Couldn't find the trigger to this, yet, maybe someone's willing to help investigating._________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

That's imho not enough to pull in these deps. (If I missed something, tell me)._________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Edit 2: I find it a little strange to install a .pdf in /usr/share/info where normally only (compressed) info-pages are stored?!_________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.