yum + cache delete files after.
by Balint Cristian
Hi !
Can yum be setted to delete files from /var/cache/yum*** after upgrading/updateing ?
I dig the man but probablyI miss something or is not possible ?
Thanks,
Cristian
--
Life in itself has no meaning.
Life is an opportunity to create meaning.
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
19 years, 3 months
gconfd-2 does not exit when a user log out, breaks unmounting home
by W. Michael Petullo
I have been having some trouble with gconfd-2 (currently using GConf2-2.4.0
from RawHide PPC) for quite some time. I tried to get some discussion going
on Red Hat's Bugzilla quite a while ago but nothing really came of it. I'd
be willing to work on a patch, but I'd like to come to consensus on the
technique we should use to fix the problem. I thought perhaps I would try
this forum.
The gconfd-2 daemon is run by many GNOME applications to manage
configurations. Gconfd-2 remains running for some time after the application
which used it quits. This allows other applications to use gconfd-2 without
having to start and stop the daemon too much. This is a good idea.
The problem comes when a system tries to unmount a user's home directory when
the user logs out. For example, pam_mount unmounts an encrypted home
directory then I log out of my system. Other people use NFS or other means
to mount home directories.
Gconfd-2 continues to run even when a user logs out. This causes the
unmounting of the user's home directory to fail because gconfd-2 keeps the
following files open:
/home/user/.gconfd/saved_state
In addition, when using GNOME 2.4, there are four new programs that seem to
hang around unwelcome for a second after logging out (at least they are still
around when PAM session closing code is run). This is partially documented
in bug #106826. The four programs are:
bonobo-activation-server (home direcotry remains open as CWD?)
gnome-settings-daemon (home direcotry remains open as CWD?)
xscreensaver -nosplash (home direcotry remains open as CWD?)
mapping-daemon (home direcotry remains open as CWD?)
Red Hat Bugzilla bugs #67605, #75895 and #106826 comment more on this
problem.
--
Mike
19 years, 3 months
Distags in rpm sort order (yes, versioning again ;)
by Axel Thimm
Bringing up this topic again, since it was left unresolved.
I won't go into details again, about *why* a disttag is needed and why
it has to adhear to rpm internal sort algorithms. Please check the
following threads in doubt (and discuss the reasons there please, help
keeping this thread constructive this time ;):
http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00272.html
http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00551....
http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00263....
The bottom line is that distags are needed if one wants to create
packages for the same upstream sources but built for different
distributions. Disttags can then be embedded in the release tag to
ensure proper upgradability.
==================== Disttag schemes: pick one!
Here are the discussed schemes (some others exist with small
variations, e.g. fc instead of fdr, or no fdr tag at all, the
discussion is the same). Default versioning is (no cvs/beta, kernel
modules and special cases, leave that for another thread):
<name>-<upstream version>-<releasenumber><disttag><non sort relevant suffixes, e.g. repoid>
e.g. simply
foo-1.2.3-4.<disttag>.johnsmith
disttag can be:
A B C
Red Hat Linux 7.3 fdr0.7.3 rh7.3 rh7.3
Red Hat Linux 8.0 fdr0.8.0 rh8.0 rh8.0
Red Hat Linux 9 fdr0.9 rh9 rh9
Fedora Core 1 fdr1 rh9.1 1fdr
Fedora Core 2 test1 fdr1.95 rh9.1.95 1.95fdr
A) + consistent distid
+ future tagging will be self-explanatory
+ fits nicer into a general nameing scheme (e.g. not only RHL and
FDR, but RHEL and non-RH could use, or allready do use the
<disttag>:=<distid><distversion> idiom)
- obfuscates RHL <= 9 rpm versioning
- requires rebuilding of existing 3rd party repos for the sake of
versioning.
o requires a statement from redhat to allow calling RH 7.3 as FDR
0.7.3 for instance, e.g. the "old" RHL product is officially
conamed Fedora 0.something
B) + current practice for many repos offering rpms build form the same
upstream sources for more than one distribution.
+ keeps current 3rd party repos from rebuilding all the old rpms
just for reversioning (and users from redownloading the same rpms
with a new name)
- does not pertain the strict separation RHL <-> FDR, and may cause
confusion.
o A) is preferable, but B) may be a nice transition solution for
existing installations.
C) + visually pertains separation of rh and fdr releases
- is a kludgy workaround using rpm semantics present only after
RHL9, thus breaking upgrading from RH8.0 and less (note that rpm
errata for fixing this rpm bug and others are still not
officially available)
- number prefixing breaks when the preceding expression is numeric
separated with dots or underscores, e.g.
foo-1.2.3-1.1_rh9 > foo-1.2.3-1_1fdr
(the stems here are "foo-1.2.3-1.1" < "foo-1.2.3-1")
Using decimal release tags needs to be separately considered, but
the fact is that they are being used often.
- reverses order of distid and distversion
- Variant "1fdr<version>" keeps order of distid and distversion,
but breaks in all other ways above, as well as introducing an
obfuscating decimal in the release tag.
I hope RH agrees to using A) or a variant thereof. In any case it
would be beneficial if an "official" solution could be blessed, so
that 3rd party repos don't have to reinvent their own
versioning.
Certainly many repos will start offering their packages (officially)
after FC1 is (officially) released, so there are only a few days left
...
In order to not molest users with forced downloads for reversioning
rpms for older RHL releases, I would suggest to use B) in a transition
phase for large rpms that do not need updating other than the
reversioning. After some time B) will have been phased out.
C) is not really an option. It will break more than it is intended to
salvage.
Also it would be nice to have rawhide versioning, e.g. immediately
after a release update fedora-release to the next test release
version or something below to indicate rawhide builds.
Thank you for your time.
--
Axel.Thimm(a)physik.fu-berlin.de
19 years, 7 months
Warren's Package Naming Proposal - Revision 1
by Warren Togami
http://www.fedora.us/wiki/PackageNamingGuidelines
The following is based upon current fedora.us package naming guidelines,
quickly edited and dramatically simplified because fedora.redhat.com no
longer needs many of fedora.us special considerations.
The below proposal is ALMOST EXACTLY THE SAME as fedora.us current
scheme except with the leading "0.fdr." removed from all %{release}
tags. I would assert that fedora.us package naming scheme has
demonstrated to be a great success, thus it should continued in
fedora.redhat.com. The below scheme is also in-line with the common
practices used by most of Red Hat's existing packages.
This proposal is missing considerations for 3rd party repositories.
Theoretically 3rd party repositories should no longer have a reason to
publish the same %{name} of any packages that exist in FC or FE because
changes should be incorporated upstream. There are however some cases
like kde-redhat where this is not possible, so we really need to discuss
possible solutions to this. Earlier we had discussed the possibility of
simply adding a %{reptag} to the far right of %{release}.
Fedora Package Naming Guidelines
Warren's Proposal for fedora.redhat.com
Revision 1
================================
i. Introduction
Goals for package naming guidelines
ii. Terminology
A. Package Name
B. Version
C. Release Tag
1. Release Prefix
2. Vepoch
3. Non-Numeric Version to Release
4. Dist tag
5. Special: Kernel modules
6. Special: Plugin, theme etc packages
7. Special: Minor Number
i. Introduction
===============
Goals for the Fedora Package Naming Guidelines
* Easily understandable package naming policy
* Indication of the original source version (end-user convenience)
* Allow for a smooth upgrade path between multiple levels of testing
branches and future distribution upgrades. This means E-V-R must never
be exactly identical between distribution versions.
* Minimize the chance of package conflicts for future Fedora
distribution upgrades.
ii. Terminology
==============
name
This is the "Name" field of RPM .spec files.
version
This is the "Version" field of RPM .spec files.
release tag
This is the "Release" field of RPM .spec files.
dist tag
This is a distribution tag indicating which RHL/FC distribution this
package is intended for. This only occurs in cases where packages from
different distributions are built from the same SRPM and patchlevel.
vepoch
This is our term for "version specific epoch", used in all packages as a
simple means of ensuring upgrades by simple incrementing the leading
number within the release tag. vepoch is otherwise known as "release
number" or "patchlevel". Read C-2 for more information.
E-V-R
Abbreviation for epoch, version, and release. This is often referred to
when talking about potential package upgrading problems.
A. Package Name
===============
Package name should preferably match the upstream tarball or project
name from which this software came. In some cases this naming choice is
more complicated. If this package has been packaged by other
distributions/packagers (Mandrake, SuSE, Conectiva, PLD, PLF, FreshRPMS,
etc.) in the past, then we should try to match their name for
consistency. In any case, try to use your best judgement, and other
developers will help in the final decision.
Ultimately it is up to QA to decide upon the proper %{name} before
publication.
B. Version
==========
If the version is only numbers, then these numbers can be put into the
"version" field of the RPM .spec unchanged. If the version contains
non-numeric characters, this creates several problems for RPM version
comparison and a broken upgrade path.
Example:
foobar-1.2.3beta1.tar.gz
foobar-1.2.3.tar.gz
While the "1.2.3" version is newer than the 1.2.3beta1 version, RPM
version comparison thinks the former is newer.
Example:
foobar-1.0a
foobar-1.0b
The "1.0b" version is higher than "1.0a", but all versions of RPM prior
to rpm-4.2-0.55 are confused when it tries to compare letters. Whichever
package is first in the comparison "wins", thus this becomes a two way
upgrade problem. This a < b comparison works properly only in RH9 and
higher.
For simplicity, Fedora treats both pre-release and post-release
non-numeric version cases the same, making the version purely numeric
and moving the alphabetic part to the release tag. Take the numeric
portion of the source version and make that the package version tag.
Read C-3 for more details.
C. Release Tag
==============
The release tag of Fedora packages more complicated, so this is split
into several parts.
C-1. Release Prefix
-------------------
No longer needed in fedora.redhat.com.
C-2. Vepoch
-----------
The leftmost leading number within the release tag is the "version
specific epoch" or vepoch in Fedora. This number is incremented with
every package update. The vepoch is otherwise known as the "release
number" or "patchlevel".
The key difference between the concept of "vepoch" and "patch level" is
that everything to the right of the vepoch is PURELY INFORMATIONAL. The
only time where it matters is to guarantee a different %{release} tag
between two distribution versions.
The vepoch is to be respected by Fedora Core/Extras/Alternatives/Legacy
as canonical. Package updates in any repository should always check all
other official repositories to be sure that the vepoch is always
incremented and never matching an existing package.
With most normal packages, vepoch is a single number starting at "1".
Under the (C-3) non-numeric version case it is two numbers starting at
"0.1" with the second number being the number to increment.
Normal Package Example:
foobar-1.2.3-1.src.rpm compiles to
foobar-1.2.3-1.i386.rpm
If this package is patched:
foobar-1.2.3-2.i386.rpm
foobar-1.2.3-3.i386.rpm
C-3. Non-Numeric Version to Release
-----------------------------------
As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric
versioned packages can be problematic so they must be treated with care.
These are cases where the upstream version has letters rather than
simple numbers in their version. Often they have tags like alpha, beta,
rc, or letters like a and b denoting that it is a version before or
after the number. Read section B to understand why we cannot simply put
these letters into the version tag.
Release Tag for Pre-Release Packages:
0.%{X}.%{alphatag}
Release Tag for Non-Numeric Post-Release Packages:
%{X}.%{alphatag}
Where %{X} is the vepoch increment, and %{alphatag} is the string that
came from the version.
Example (pre-release):
mozilla-1.4a.tar.gz from usptream is lower than
mozilla-1.4.tar.gz the later "final" version thus
mozilla-1.4-0.1.a Fedora package name
Example (pre-release):
alsa-lib-0.9.2beta1.tar.gz becomes
alsa-lib-0.9.2-0.1.beta1
Example (post-release):
gkrellm-2.1.7.tar.gz
gkrellm-2.1.7a.tar.gz Quick bugfix release after 2.1.7
gkrellm-2.1.7-1.a
Upgrade Path Example (mozilla):
mozilla-1.4-0.1.a
Patched
mozilla-1.4-0.2.a
Patched again
mozilla-1.4-0.3.a
Move to 1.4b
mozilla-1.4-0.4.b
Patched
mozilla-1.4-0.5.b
Move to 1.4 "final" version
Notice that this becomes a normal C-2 case
mozilla-1.4-1
Patched
mozilla-1.4-2
Upgrade Path Example (alsa-lib):
alsa-lib-0.9.2-0.1.beta1
Patched
alsa-lib-0.9.2-0.2.beta1
Move to beta2
alsa-lib-0.9.2-0.3.beta2
Move to beta3 and simultaneously patch
alsa-lib-0.9.2-0.4.beta3
Patched again
alsa-lib-0.9.2-0.5.beta3
Move to rc1
alsa-lib-0.9.2-0.6.rc1
Move to rc2
alsa-lib-0.9.2-0.7.rc2
Move to "final"
alsa-lib-0.9.2-1
Patched
alsa-lib-0.9.2-2
C-4. Dist tag
-------------
In cases where the same SRPM and patchlevel is used between two or more
distributions supported by Fedora, a dist tag is appended to the end of
the release tag defined in C-2 and C-3. The dist tags with the
following examples appear to be only cosmetic, however the a different
E-V-R is needed between distributions to ensure dist upgrading works
fully in all corner cases.
Dist Tag for Normal Packages:
%{X}.%{disttag}
Where %{X} is the vepoch and %{disttag} is a distribution tag from this
table:
0.7.3 Red Hat Linux 7.3
0.8 Red Hat Linux 8
0.9 Red Hat Linux 9
1 Fedora Core 1
1.93 Fedora Core 1.93 beta
1.94 Fedora Core 1.94 beta
2 Fedora Core 2 beta
Example:
foobar-1.2.3-1_0.7.3.i386.rpm
foobar-1.2.3-1_0.8.i386.rpm
foobar-1.2.3-1_0.9.i386.rpm
foobar-1.2.3-1_1.94.i386.rpm
foobar-1.2.3-1_2.i386.rpm
Upgrade Path Example (FC1 only shown):
foobar-1.2.3-1_1.i386.rpm
foobar-1.2.3-2_1.i386.rpm
foobar-1.2.3-3_1.i386.rpm
Dist Tag for Pre-Release Packages:
%{X}.%{alphatag}.%{disttag}
Where %{X} is the vepoch, %{alphatag} is the pre-release tag described
in C-3, %{disttag} is a distribution tag described above.
Example:
alsa-lib-0.9.2-0.1.beta1_0.8.i386.rpm
alsa-lib for RH 8.0
alsa-lib-0.9.2-0.1.beta1_1.i386.rpm
alsa-lib for FC1
Upgrade Path Example (RH 7.3 only shown):
alsa-lib-0.9.2-0.1.beta1_0.7.3
alsa-lib-0.9.2-0.2.beta1_0.7.3
alsa-lib-0.9.2-0.3.beta2_0.7.3
alsa-lib-0.9.2-0.4.beta3_0.7.3
alsa-lib-0.9.2-0.5.beta3_0.7.3
alsa-lib-0.9.2-0.6.rc1_0.7.3
alsa-lib-0.9.2-0.7.rc2_0.7.3
alsa-lib-0.9.2-1_0.7.3
alsa-lib-0.9.2-2_0.7.3
C-5. Special Case: Kernel modules
---------------------------------
This section needs its own discussion due to changed provides within
FC1's kernel, and the fact that older distributions are different.
C-6. Plugin, theme etc packages
-------------------------------
Packages that are plugins, themes or the like, ie. enhance other
packages must be named <package-to-enhance>-<enhancement>. If the
resulting name differs significantly from upstream naming, a
Provides: <upstream-name> = %{epoch}:%{version}-%{release}
must be added. For example:
Upstream package name: modplug-xmms
Fedora package name: xmms-modplug
Provides: modplug-xmms = %{epoch}:%{version}-%{release}
C-7. Minor Number
-----------------------
Probably no longer needed at fedora.redhat.com.
19 years, 7 months
Self-Introduction: Logan Rathbone
by Logan Rathbone
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~Logan A. Rathbone~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~Mississauga, Ontario, Canada~~~~~~~~~~~~~~~
~University student - 1st year of studies in Economics~
~~~~~~~~~~~~~~~University of Toronto~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~My goals in the Fedora Project:~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There have been many myths surrounding Linux on the desktop. It is an extremely common perception of many people, namely those that have never parted from Microsoft's operating systems, that Linux is difficult to use. While many Linux users try day after day to dispell many of these myths, 99% of PCs are still running Windows. I believe that it is time for us to ask, "why?" Many Linux users today, especially those who are very experienced with Linux and computing in general, feel that the opinions of these users do not count. I believe that nothing could be farther from the truth. These users need to be convinced that the time for them to change their operating system is NOW.
However, while Linux is an operating system that is so superior to Windows in so many ways, there are several issues that need to be ironed out. In the case of what was previously Red Hat Linux and is now the Fedora Project, I believe that the issue is that of software installation. Red Hat started to address this problem fairly recently with their up2date tool. While the tool itself is wonderful, it is just a tool (as are yum, apt, etc. as well.) I feel that what Fedora needs at this point (among other things, of course) is a strong package repository, like what users of Debian have already. I actually switched from Red Hat to Debian because of that at one point. However, I returned in the other direction as soon as I heard about the Red Hat-Fedora merger. I am _not_ saying Fedora needs to become Debian. Debian lacks the professionalism that has always been sought by Red Hat distributions of Linux. In other words, I feel that Fedora users should have the best of bo!
th worlds -- a strong library (quality _and_ quantity) of software available, in the form of a yum repository (ie: rawhide) _and_ a professional, unique and sleek operating system that will make many home users of Windows take a run for their money.
I am a very recent adopter of Linux -- I started in June 2003, just a few short months ago. I know what it's like to be a Windows user, and I know what kind of software home users want. That is why I feel that it is my _duty_ to be a packager of supplementary software for the Fedora Project. When Fedora users are browsing the internet or IRC and hear about a cool new software package XYZ, they should be able to type "yum install XYZ" and have that package on their machine, without so much as a fuss. But of course, I and the other packagers would take legal issues into mind and only package software that complies with the legal entities of the Fedora Project.
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Historical Qualifications~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
In truth, I have very few. But, one must start somewhere. I am quite heavily involved in certain aspects of the Ark Linux distribution (www.arklinux.org) and have done some minor package building (RPMs) as well as general community support. I believe that my one true qualification is the fact that I am still, at heart, a home PC user. I am not a power-user, I am not a programmer, and I am not by any means a developer. I am simply your average-Joe home computer user that knows how to build RPM packages. In the case of my role in this project, however, I feel that my lack of technical expertise can be seen as more of an asset and less a liability. Most Windows users that convert to Linux don't know about the 2 main desktop environments. They don't understand the concept of window managers, the kernel, bash and other shells, X, etc. To them, Linux is Linux is Linux; they want to try it because they've heard about how it is a more stable, more secure, and generally a be!
tter computing environment than Windows. I understand this mentality (I was there just last June, remember?) and I will certainly take it into account when selecting and building packages.
You should trust me for one reason, and for one reason only -- for the past months, I have been utterly compelled and even obsessed with the Linux operating system, and I have placed my entire trust in Linux and the Linux community. I have gone from distribution-to-distribution, each time more disappointed than the last. However, I have finally seen light at the end of the tunnel. That light is, of course, the Fedora Project.
I hope dearly that I will be permitted to contribute to this wonderful project,
Logan "Poprocks" Rathbone
[logan@localhost logan]$ gpg --fingerprint BF86D3F4
pub 1024D/BF86D3F4 2003-10-30 Logan Rathbone (Poprocks) <poprocks(a)linux.net>
Key fingerprint = AA14 D6F3 0F7B 650B 5E7C A588 33D8 77F7 BF86 D3F4
sub 2048g/296BEE8D 2003-10-30 [expires: 2008-10-28]
_____________________________________________________________
Linux.Net -->Open Source to everyone
Powered by Linare Corporation
http://www.linare.com/
19 years, 7 months
Run prelink and other stuff not in cron but when screensaver is active.
by Jaap A. Haitsma
I sometime get a bit frustrated that a cron job starts while I'm
working. Wouldn't it be nicer that this stuff would run when I'm not
doing any work. I.e. when the screensaver is active. Maybe as a minor
enhancement when the screensaver is active and there is not a process
asking for cpu power /disk access. Sometimes I'm running compiling jobs
which take quite a while.
Jaap
19 years, 7 months
Packages RFC
by George Garvey
For my own purposes, I'm going to package:
prcs
qmail
distcc
gcc to mingw cross-compiler
fltk
I doubt qmail is of interest to Fedora, but what about the others? Want
them passed on?
19 years, 7 months
Enhanced Logrotate from Suse
by Keith Lofstrom
/usr/sbin/logrotate is the program that moves and renames files in
/var/log. On Redhat systems, it typically does this by numbering and
renumbering - messages becomes messages.1, .1 becomes .2, etc. This
makes life difficult for rsync backups, which saves each copy of each
renumbered file.
Ruediger Oertel at Suse (ro(a)suse.de) has some patches that enhance the
basic Redhat Logrotate with "dateext". This allows a dated extension
rather than a numbered one, i.e. messages.29102003 . The old logfiles
do not get renamed, just discarded after they get too old. This is a
lot easier on rsync, and it also is easier to administer.
Ruediger's patches do not change the current logrotate behavior, just
adds the new features. His patch to logrotate 3.6.10 can be found at:
ftp.suse.com/pub/people/ro/logrotate
Suse has been making these patches to RH logrotate for years, and I've
been running versions of their code for a few weeks while still using
the old logrotate method for testing. It would be nice to fold this
into the main line of fedora/redhat and eliminate a needless code fork.
Who do I talk to in order to make this happen?
Keith
BTW, this is the third attempt at sending this, though perhaps the
first clueful attempt ... :-)
--
Keith Lofstrom keithl(a)ieee.org Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
19 years, 7 months
XFree86 & Neomagic: DRI missing?
by Patrick
Fully updated Fedora as of Oct 30, 23:15 CET. When I run glxgears it
complains: Xlib: extensions "XFree86-DRI" missing on display ":0.0".
I thought 3D hardware acceleration was supported on the Neomagic NM2200.
Any ideas?
TIA,
Patrick
19 years, 7 months
