Custom Partition Fedora 18

[Gordan Bobic]

On 02/18/2013 11:26 AM, Tim wrote:
> On Sun, 2013-02-17 at 23:29 +0000, Gordan Bobic wrote:
>> Personally, I use CentOS/Scientific Linux in most cases, and only use
>> Fedora when I absolutely have to. I find (and file) way too many bugs
>> in supposedly stable EL as it is.
>
> You will be screwed if the only solution to a fault is going to be a new
> release of the software that won't be made for your long term distro,
> but the next one that won't be released for a very long time.  I've seen
> that before.

Me too, especially since most developers always target the latest and 
greatest, and if (and that is a big if) they ever do release a version 
targeted at a LT stable version, it is done much later as an afterthought.

Steam being one such example - not that they have a rpm package at all, 
and it requires a glibc too new for it to run on EL6.

>> With Fedora I've given up filing bugs because most of them get
>> auto-closed when the release goes EOL without ever having been looked
>> at or addressed. From what I can tell, if you're not filing against
>> rawhide, there's no point in filing a Fedora bug.
>
> That really shouldn't be the case, though.  You report against a
> package, such as Apache, more specifically the source.  So if your
> reported fault can be found in the current package, then it should be
> fixable.  If the fault can't be found (such as it being dependent on
> something on your system, or 32 bit versus 64 bit, and you and the
> maintainer have the opposites), then that makes it harder.

You are more talking about filing bugs upstream to the package itself, 
rather than the distro. The Distro maintainers are supposed to (or at 
least that's what I _thought_) assess whether the bug is distro specific 
or should be passed upstream and deal with it. But I cannot recall a 
single instance where I filed a bug against Fedora and had it fixed or 
even reassigned into the next release - it always seems to get left to 
rot until the EOL bot closes all remaining bugs for the release. At 
least if you file it against rawhide, it might stay alive for long 
enough to sit on somebody's todo list for long enough to annoy them into 
doing something about it eventually.

> And, like I
> said earlier, if the fix has to be part of the next release, rather than
> can be handled in the next update, you can be stuffed.

I have, indeed, had this problem in the past, but thankfully the 
majority of the time, at least the most important things seem to work on 
EL, and the rest of the time living without a particular piece of 
software is easier than living with all the bugs of a perpetual 
pre-alpha quality change-for-the-sake-of-change bleeding edge release 
just so you could indulge in a piece of software written by those 
enslaved to endlessly pursuing the latest and least stable releases of 
the supporting libraries.

Gordan