Update Fedora to a new Major-Version while running
by Thorsten Leemhuis
Hi *,
will it be "official supported" to update from one Fedora-Core to the
next major Fedora-Core Version while the machine is doing it's normal
(server) work? Like a "rpm -F *" on a RHL8 machine in a directory with a
rpms of RHL9. (Does this really work? I never tried, but was told it would.)
Okay, one reboot (needed to run the new kernel) will be needed and is
IMHO okay, but a downtime of 30 min or 1h and waiting in the
surroundings of the machine to change the CDs is sometimes very disturbing.
Especially if I'm forced to update at least once a year if security
updates will only be provided for the current and the last Fedora-Core
Version (Yes, I know, I can buy Red Hat Enterprise Linux if I really
need longer support, but that is not always an option for small/medium
sized home servers or firms).
CU
Thorsten Leemhuis
20 years, 7 months
Re: Fedora Project: Announcing New Direction
by Jef Spaleta
Havoc wrote:
> The intent _is_ to add the latest released versions of packages,
> though, to have feature updates rather than bugfixes-only, and to have
> frequent releases.
I hope there is still more room for the 'right' people to discuss some
of the intended qualities of what fedora is going to have. As an
outsider looking in at the development process that is being built
around fedora...i get the feeling that the frequent release cycles might
not sit well with a segment of the community that has a large potential
to provide competent and meaningful contribution as new members to this
process...the .edu admins and the small companies that provide .edu
hardware for starters, though I think there are a lot of R&D facility
administrators like cluster facilities at .gov that are on the fence
about participating in this community. People who could and would become
invested...if they thought Fedora was going to be something that could
be developed to scratch their needed itch.
Hopefully the shaping of the 'intent' is subject to some sort of
sweat-equity. If I could harp on the release cycle issue a little bit
more from my outside perspective, for a moment. I think the policies
around Fedora Legacy might be a good place to resolve some issues that
are keeping some contributors on the fence and not investing their time
into this community. If the fast paced EOL of Core is the big issue they
have problems with, they could first become involved through Fedora
Legacy maintenance to scratch their own itch over the EOL issue. In the
process they could earn some sweat-equity to influence the intent and
direction of core.
I think the stated intent and objectives on the current website and
Havoc's re-iteration here on the mailing list are probably a best effort
description of where the interest and constraints of current set of
contributors lie. The real trick, is going to be giving the important
people who have different interests an entry point into the process
early on, so new people can invest their mutant genes in the
evolutionary process.
-jef"If Fedora was a Hollywood motion picture...Red Hat would get
executive producer credits"spaleta
20 years, 7 months
O/T: querying an installed RPM's spec file
by Kevin Worthington
Hello everyone, sorry for this O/T post, but I know there are many people on this list who may be able to help me.
I'd like to know if there is a way to query an already installed rpm to view the spec file that was used to build it.
(Sort of like the way you can view the changelog, uusing the --changelog switch)
At the moment, I am thinking that this is not possible. Please confirm if this is the case, or how I could do it. Unfortunately the RPM in question is a bit older and I can not find a src.rpm on the net anywhere.
TIA,
Kev
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
20 years, 7 months
Some "Product Relationship" questions
by Barry K. Nathan
I have some questions regarding the info on this page:
http://fedora.redhat.com/about/rhel.html
I'll just try asking the questions in random order...
It says the "Update Lifetime" will be "2-3 months after next release".
Combine that with a "Release Interval" of 4-6 months, and that would
suggest an "Update Lifetime" of 6-9 months, not the 12 currently listed
on: https://www.redhat.com/apps/support/errata/
This looks like another change in errata policy. (In addition to the
info on the chart, I'm assuming the current policy for "Red Hat Linux"
does not automatically apply to "Fedora Core" based on the name change
alone, if nothing else.) Is this a correct interpretation of the
situation?
Also, the chart lists "Developer Community" as "Testers". To the best of
my knowledge, Red Hat QA was involved with previous Red Hat Linux
releases. Are they out of the loop now, or do they somehow fall under
the "Developer Community" umbrella?
Finally, since the "Update Source" will be the "Developer Community",
will Red Hat still list the errata on the
https://www.redhat.com/apps/support/errata/ site for Fedora Core, as it
does now for Red Hat Linux?
Thanks in advance.
-Barry K. Nathan <barryn(a)pobox.com>
20 years, 7 months
RFC: Back-ported errata RPMs for EOL Red Hat releases
by rhllist＠assursys.co.uk
Hi -
Assursys are evaluating the viability of providing back-ported errata
packages for Red Hat Linux releases that have reached their official
End-of-Life, such as the 7.3 and 7.2 releases.
If this service is of interest to your organisation, please get in touch
(either privately, or on this list); we're particularly interested in
hearing which releases we should prioritise on (our hunch is 7.3, 7.2, 8,
7.0, in that order), and how much such a service is worth to your
organisation.
At present, for insurance reasons, we can only offer such a service to EU
customers.
Best Regards,
Alex.
20 years, 7 months
Re: Fedora Project: Announcing New Direction
by Xose Vazquez Perez
Paul Gear wrote:
> My point was that some people need a longer release cycle without support.
>
> Here's my explanation of what i'm looking for:
> http://paulgear.webhop.net/the_page_formerly_known_as_rhel.html
Maybe your ideal life time is toooo much for Red Hat guys.
I like the mdk way, they have 1 year of lifetime + 6 months
_only_ for 'base' components: http://www.mandrakesecure.net/en/productlifetime.php
SuSE on the other side:
"_At the moment_ we are maintaining SuSE Linux for 2 years - that means
Bug fixes and Security fixes will be released for two years for each SuSE
Linux version. Contrary to our business products with maintenance this is
_not_ guaranteed."
--
Que trabajen los romanos, que tienen el pecho de lata.
20 years, 7 months
Redhat certification
by William L. Sebok
>> May i add another question, how does the above affect the RHCE/RHCT
>>certification programs?
>It does not. RHCE/RHCT are based on the enterprise RHL. This was announce
>when RHL9 came out.
I just received my RHCE a week ago. It was based on Redhat 9.
Bill Sebok Computer Software Manager, Univ. of Maryland, Astronomy
Internet: wls(a)astro.umd.edu URL: http://furo.astro.umd.edu/
20 years, 7 months
How did ya'll do in the storm?
by Troy Dawson
Please note. This is NOT a 'when will the website be updated' e-mail
Hi,
Since this is sorta the community list, I'm sure others in the community are
curious how well RedHat weathered the storm. I looked through redhat's web
pages, and the other community mailling lists and didn't see any mention.
Did RedHat's headquarters get missed by the storm, or did ya'll get plasterd?
Were you part of the area that had power outage, or storm surge?
Any fun stories you'd mind sharing?
I know I could look up RedHat's address and then compare where the storm when
and so forth, but I had a hard enough time figuring out if my neice was hit or
not, that I thought I'd ask. Besides, you can't get any fun stories is you
find out that way.
If you have something better to do, then don't bother responding to this
e-mail, but if you're someone there that has a few minutes, there are those of
us out here that are curious.
Troy Dawson
--
__________________________________________________
Troy Dawson dawson(a)fnal.gov (630)840-6468
Fermilab ComputingDivision/CSS CSI Group
__________________________________________________
20 years, 7 months
