After repeated (heated) discussions over init scripts, I wanted to guideify my thoughts (and others) on this. Can we have some discussion over this draft and vote at next meeting?
http://fedoraproject.org/wiki/PackagingDrafts/InitScripts
On Fri, Feb 16, 2007 at 06:00:40PM -0500, Jesse Keating wrote:
After repeated (heated) discussions over init scripts, I wanted to guideify my thoughts (and others) on this. Can we have some discussion over this draft and vote at next meeting?
I would be more stringent than that and require packages to transit into non-%config init files. E.g. to make a temporary exception and explicitely say that this exception will be lifted later. The migration should be done in the new package's %prein script.
Also a side-note: The text could be read as "all config information must be under /etc/sysconfig", maybe this needs to be clarified to mean any config bits, not already dealt with in the package's native config space under /etc? I had a couple of times where people argued that everything pertaining to configuration needs to be placed under /etc/sysconfig, so the policy could be misread by them.
Axel Thimm (Axel.Thimm@ATrpms.net) said:
I would be more stringent than that and require packages to transit into non-%config init files. E.g. to make a temporary exception and explicitely say that this exception will be lifted later. The migration should be done in the new package's %prein script.
Why would changing from %config to non-%config require changes in the scriplets at all?
Bill
On Mon, Feb 19, 2007 at 11:26:19AM -0500, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@ATrpms.net) said:
I would be more stringent than that and require packages to transit into non-%config init files. E.g. to make a temporary exception and explicitely say that this exception will be lifted later. The migration should be done in the new package's %prein script.
Why would changing from %config to non-%config require changes in the scriplets at all?
The above referred to the following part of the draft:
"A valid exception to this rule would be existing packages where configuration is still done via the init file. In this case, the init file could be marked as %config to preserve a users configuration upon upgrade, hopefully so that the user can migrate said configuration to a new /etc/sysconfig/<service> config file."
Does it make more sense now?
Axel Thimm (Axel.Thimm@ATrpms.net) said:
Why would changing from %config to non-%config require changes in the scriplets at all?
The above referred to the following part of the draft:
"A valid exception to this rule would be existing packages where configuration is still done via the init file. In this case, the init file could be marked as %config to preserve a users configuration upon upgrade, hopefully so that the user can migrate said configuration to a new /etc/sysconfig/<service> config file."
Does it make more sense now?
No. If it changes from %config (modified) to non-%config, it would still get moved on upgrade, unless I'm forgetting the state machine.
Bill
On Mon, Feb 19, 2007 at 11:33:21AM -0500, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@ATrpms.net) said:
Why would changing from %config to non-%config require changes in the scriplets at all?
The above referred to the following part of the draft:
"A valid exception to this rule would be existing packages where configuration is still done via the init file. In this case, the init file could be marked as %config to preserve a users configuration upon upgrade, hopefully so that the user can migrate said configuration to a new /etc/sysconfig/<service> config file."
Does it make more sense now?
No. If it changes from %config (modified) to non-%config, it would still get moved on upgrade, unless I'm forgetting the state machine.
That's why I suggested %prein
Axel Thimm (Axel.Thimm@ATrpms.net) said:
No. If it changes from %config (modified) to non-%config, it would still get moved on upgrade, unless I'm forgetting the state machine.
That's why I suggested %prein
I think we're talking past each other. AFAIK, it will get successfully saved as .rpmsave *without* any %pre magic.
Bill
On Mon, Feb 19, 2007 at 12:33:54PM -0500, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@ATrpms.net) said:
No. If it changes from %config (modified) to non-%config, it would still get moved on upgrade, unless I'm forgetting the state machine.
That's why I suggested %prein
I think we're talking past each other. AFAIK, it will get successfully saved as .rpmsave *without* any %pre magic.
Indeed, my issue is to have the upgrade do something with the existing configuration in some scripts, not simply archive away the user's config into an .rpmsave file. The upgrade would break on the user and leave him fiddle out where his config has vanished to.
And the cleanest way is for the package to extract the config out of the script and place it to the new canonical place during the upgrade. Hopefully the config will be in some extractable form.
Note: We are talking only about package that don't only tag init files as %config, but indeed misuse them to store config information. Not that I know of any to present an example, but Jesse said there are some. This has nothing to do with the tons of packages marking init files as %config even though all config has been moved to sysconfig ages ago.
Perhaps it become clearer if we find such a package and discuss what we'd like an upgrade to perform.
On Mon, 2007-02-19 at 18:47 +0100, Axel Thimm wrote:
On Mon, Feb 19, 2007 at 12:33:54PM -0500, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@ATrpms.net) said:
No. If it changes from %config (modified) to non-%config, it would still get moved on upgrade, unless I'm forgetting the state machine.
That's why I suggested %prein
I think we're talking past each other. AFAIK, it will get successfully saved as .rpmsave *without* any %pre magic.
Indeed, my issue is to have the upgrade do something with the existing configuration in some scripts, not simply archive away the user's config into an .rpmsave file. The upgrade would break on the user and leave him fiddle out where his config has vanished to.
IMO, the logic should be: Do not replace /etc/init.d scripts a user had altered, only replace those without changes. => %config(noreplace)
Normal users will not notice anything, users customizing init-scripts will have to "know what they are doing".
Perhaps it become clearer if we find such a package and discuss what we'd like an upgrade to perform.
E.g. customizing/fixing init priorities, buggy init-scripts with local bug-fixes applied, ...
Theoretically, such things should not exist, but things happen ...
Ralf
Ralf Corsepius (rc040203@freenet.de) said:
Perhaps it become clearer if we find such a package and discuss what we'd like an upgrade to perform.
E.g. customizing/fixing init priorities,
There are overrides for this in rawhide. See the latest chkconfig package.
buggy init-scripts with local bug-fixes applied, ...
That could apply to *anything*, whether it be /usr/bin/find or /etc/init.d/sshd. Special-casing something just because it happens to be shell seems misguided.
Bill
On Mon, 2007-02-19 at 13:10 -0500, Bill Nottingham wrote:
Ralf Corsepius (rc040203@freenet.de) said:
Perhaps it become clearer if we find such a package and discuss what we'd like an upgrade to perform.
E.g. customizing/fixing init priorities,
There are overrides for this in rawhide. See the latest chkconfig package.
buggy init-scripts with local bug-fixes applied, ...
That could apply to *anything*, whether it be /usr/bin/find or /etc/init.d/sshd.
Yes, ... if you want to drive this to extremes, one could argue this to be a missing feature in rpm.
Special-casing something just because it happens to be shell seems misguided.
Whether this is special casing depends on your view "/etc ... /etc/ == configuration" == no special casing.
Apart of this, a system is not unlikely not to boot up anymore or at least not to work properly anymore when an update reverts a local bug fix/customization.
Ralf
On Monday 19 February 2007 22:31, Ralf Corsepius wrote:
Apart of this, a system is not unlikely not to boot up anymore or at least not to work properly anymore when an update reverts a local bug fix/customization.
Alternatively it may not boot or work properly if your old init script is kept in place while a newer init script with different launch options is needed for the new binary. This is why configuration must be split from launch script.
On Tue, 2007-02-20 at 08:04 -0500, Jesse Keating wrote:
On Monday 19 February 2007 22:31, Ralf Corsepius wrote:
Apart of this, a system is not unlikely not to boot up anymore or at least not to work properly anymore when an update reverts a local bug fix/customization.
Alternatively it may not boot or work properly if your old init script is kept in place while a newer init script with different launch options is needed for the new binary.
In theory yes, in practice in most cases things are the other way round: An old script continues to work unless things been deliberately changed in incompatible ways.
Or conversely: An old script is likely to degrade, if things are being changed deliberately.
This is why configuration must be split from launch script.
I don't see this - Separate config files only restrict the user to what a vendor wants him to restrict to and what the vendor has taken into consideration.
It takes away the freedom of customization and takes away the freedom extending init-scripts to what the vendor has not considered.
Why would this be useful? The user has chosen to customize, so it's the user's responsibility to handle this situation - If you take away %config you are simply erasing, killing his "carefully handcrafted solution" to a real world problem. - I can't find this helpful.
Ralf
On Tuesday 20 February 2007 08:33, Ralf Corsepius wrote:
I don't see this - Separate config files only restrict the user to what a vendor wants him to restrict to and what the vendor has taken into consideration.
It takes away the freedom of customization and takes away the freedom extending init-scripts to what the vendor has not considered.
Why would this be useful? The user has chosen to customize, so it's the user's responsibility to handle this situation - If you take away %config you are simply erasing, killing his "carefully handcrafted solution" to a real world problem. - I can't find this helpful.
And I can't see any difference between this an any other script on the file system. So unless we extend it so that all editable scripts become %config, I don't see this special casing being helpful, instead its promoting upstreams to continue to use init scripts for configuration.
On Tue, 2007-02-20 at 08:43 -0500, Jesse Keating wrote:
On Tuesday 20 February 2007 08:33, Ralf Corsepius wrote:
I don't see this - Separate config files only restrict the user to what a vendor wants him to restrict to and what the vendor has taken into consideration.
It takes away the freedom of customization and takes away the freedom extending init-scripts to what the vendor has not considered.
Why would this be useful? The user has chosen to customize, so it's the user's responsibility to handle this situation - If you take away %config you are simply erasing, killing his "carefully handcrafted solution" to a real world problem. - I can't find this helpful.
And I can't see any difference between this an any other script on the file system.
As I wrote before, if you want to take this too extremes, yes the same consideration can also be applied to any script in the system and one could go so far to state rpm not allowing this to be a bug.
The difference between an arbitrary script and /etc/init.d scripts is their history of init.d and their role.
Nobody expects arbitrary scripts to customizable. Instead, people resort to other means, such as repackaging rpms, adding custom scripts to /usr/local (exactly this is what /usr/local is for) or elsewhere (/opt, ~/bin, /root/bin).
Such workaround aren't easily applicable to init.d scripts.
So unless we extend it so that all editable scripts become %config, I don't see this special casing being helpful, instead its promoting upstreams to continue to use init scripts for configuration.
Let me ask differently: What is the problem you are trying to solve? I don't see any.
Files under /etc/* are defined as config files, therefore /etc/init.d are config-files by definition. This matches their history, matches tradition, matches common practice, is helpful to users and makes no difference to a vendor, and also makes no difference to the vast majority of users.
To the remaining minority of users it makes a substantial difference. It at least forces them to redesign their "customizations" because any update will trash their customizations.
Ralf
On Tuesday 20 February 2007 09:07, Ralf Corsepius wrote:
Let me ask differently: What is the problem you are trying to solve? I don't see any.
Inconsistency between configuration in an init file and in /etc/sysconfig/<service>, executable config files, inability to get new init scripts in place (blocked by .rpmnew), just to name a few.
Files under /etc/* are defined as config files, therefore /etc/init.d are config-files by definition. This matches their history, matches tradition, matches common practice, is helpful to users and makes no difference to a vendor, and also makes no difference to the vast majority of users.
Yes, history is a hard thing to change. However unless we want to end up like Solaris, we need to be open to refinement to our system, and such refinement could include pressure to stop configuration in an init script (which REALLY should live outside of etc, but alas...) and instead push configuration to /etc/sysconfig/<service>
To the remaining minority of users it makes a substantial difference. It at least forces them to redesign their "customizations" because any update will trash their customizations.
Yep, sucks to be them, but we use Fedora to push new technology and new ways of thinking.
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> Can we have some discussion over this draft and vote at next JK> meeting?
I can get behind this, but I think that we make the set of exceptions as narrow as possible. It should be possible to actually list out all of the packages which violate this, limit the exceptions to those and then work to shrink that list over time.
So perhaps nuke the two sentences starting with "A valid exception", and add a section "Grandfathered packages" so there is no question as to whether a new package can be excepted from the guideline.
I do anticipate that it simply might not be possible for some of these grandfathered packages to ever switch over, but at least if they're explicitly listed the question won't keep coming up about whether they violate guideline.
- J<
"JLT" == Jason L Tibbitts tibbs@math.uh.edu writes:
JLT> It should be possible to actually list out all of the packages JLT> which violate this, limit the exceptions to those and then work JLT> to shrink that list over time.
And here's a list of core packages, generated by grep -l '^%config.*init' */devel/*spec|awk -F/ '{print $1}' in a complete core checkout and edited for one false positive (e2fsprogs):
am-utils anacron apmd arptables_jf at autofs bind bootparamd Canna ccs cups cyrus-sasl dbus device-mapper-multipath dhcp dovecot fence firstboot freeradius FreeWnn GFS ghostscript glibc gpm gulm hal howl hplip hpoj httpd hwcrypto initscripts iptables iputils ipvsadm irda-utils iscsi iscsi-initiator-utils isdn4k-utils kdenetwork kexec-tools krb5 kudzu lm_sensors LPRng mars-nwe net-snmp NetworkManager nfs-utils openhpi OpenIPMI policycoreutils policy portmap privoxy quagga radvd rarpd rgmanager routed rusers rwall rwho selinux-policy selinux-policy-strict selinux-policy-targeted sendmail spamassassin squid tog-pegasus tomcat tux vixie-cron XFree86 xinetd xinitrc xorg-x11 ypbind ypserv yum zebra
Also note that a few packages use %config(noreplace).
- J<
Here's another possibly related question I found while grepping through core package specs:
Do we care about use of %{_initrddir} versus %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other?
- J<
Jason L Tibbitts III wrote:
Here's another possibly related question I found while grepping through core package specs:
Do we care about use of %{_initrddir} versus %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other?
imo, the former, since that is precisely what it exists for.
-- Rex
On Fri, Feb 16, 2007 at 07:15:22PM -0600, Rex Dieter wrote:
Jason L Tibbitts III wrote:
Here's another possibly related question I found while grepping through core package specs:
Do we care about use of %{_initrddir} versus %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other?
imo, the former, since that is precisely what it exists for.
While at it could we have the typo in the macro fixed? We can keep the old one indefinitely around for compatibility's sake.
Axel Thimm wrote :
On Fri, Feb 16, 2007 at 07:15:22PM -0600, Rex Dieter wrote:
Jason L Tibbitts III wrote:
Here's another possibly related question I found while grepping through core package specs:
Do we care about use of %{_initrddir} versus %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other?
imo, the former, since that is precisely what it exists for.
While at it could we have the typo in the macro fixed? We can keep the old one indefinitely around for compatibility's sake.
Yeah, *please* don't go deciding to use a macro which has a broken and confusing name. I'd suggest either : - Using /etc/rc.d/init.d/foo "hardcoded" in %files (as Bill writes, the path is pretty much written in stone). - Using a new "fixed" macro for people who want that (useless?) warm fuzzy feeling lines beginning with "%" give them.
Matthias
On Mon, Feb 26, 2007 at 07:15:37PM +0100, Matthias Saou wrote:
Axel Thimm wrote :
On Fri, Feb 16, 2007 at 07:15:22PM -0600, Rex Dieter wrote:
Jason L Tibbitts III wrote:
Here's another possibly related question I found while grepping through core package specs:
Do we care about use of %{_initrddir} versus %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other?
imo, the former, since that is precisely what it exists for.
While at it could we have the typo in the macro fixed? We can keep the old one indefinitely around for compatibility's sake.
Yeah, *please* don't go deciding to use a macro which has a broken and confusing name. I'd suggest either :
- Using /etc/rc.d/init.d/foo "hardcoded" in %files (as Bill writes, the
path is pretty much written in stone).
Well, /usr and /etc are even deeper carved in that stone, but we wouldn't conclude that using the respective macros is therefore even less important.
- Using a new "fixed" macro for people who want that (useless?) warm
fuzzy feeling lines beginning with "%" give them.
I vote for
+%_initdir %{_sysconfdir}/rc.d/init.d +# ancient typo kept for compatibily purposes %_initrddir %{_sysconfdir}/rc.d/init.d
It's the natural naming and already in use at several places besides ATrpms:
http://www.google.com/search?q=_initdir+-site%3Aatrpms.net
Le lundi 26 février 2007 à 19:28 +0100, Axel Thimm a écrit :
I vote for
+%_initdir %{_sysconfdir}/rc.d/init.d +# ancient typo kept for compatibily purposes %_initrddir %{_sysconfdir}/rc.d/init.d
I vote for waiting till the new init system in F8 makes it clear if %{_sysconfdir}/rc.d/init.d will even be used anymore
On Mon, Feb 26, 2007 at 07:33:44PM +0100, Nicolas Mailhot wrote:
Le lundi 26 février 2007 à 19:28 +0100, Axel Thimm a écrit :
I vote for
+%_initdir %{_sysconfdir}/rc.d/init.d +# ancient typo kept for compatibily purposes %_initrddir %{_sysconfdir}/rc.d/init.d
I vote for waiting till the new init system in F8 makes it clear if %{_sysconfdir}/rc.d/init.d will even be used anymore
Wouldn't the initfiles have to be installed somewhere? And in that case if we cater early enough we simply ship F8 with a new _initdir value pointing to the new preferred value.
Le lundi 26 février 2007 à 19:38 +0100, Axel Thimm a écrit :
On Mon, Feb 26, 2007 at 07:33:44PM +0100, Nicolas Mailhot wrote:
Le lundi 26 février 2007 à 19:28 +0100, Axel Thimm a écrit :
I vote for
+%_initdir %{_sysconfdir}/rc.d/init.d +# ancient typo kept for compatibily purposes %_initrddir %{_sysconfdir}/rc.d/init.d
I vote for waiting till the new init system in F8 makes it clear if %{_sysconfdir}/rc.d/init.d will even be used anymore
Wouldn't the initfiles have to be installed somewhere? And in that case if we cater early enough we simply ship F8 with a new _initdir value pointing to the new preferred value.
In that case it will be easier for everyone if the old macro points to the legacy init & the new to the new one, instead of muddying the waters with a premature change
Jason L Tibbitts III (tibbs@math.uh.edu) said:
Here's another possibly related question I found while grepping through core package specs:
Do we care about use of %{_initrddir} versus %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other?
Techncially, someone who redefines %{_sysconfdir} for init scripts is just asking for pain; among other things, the path is compiled in to chkconfig and various other scripts.
Bill
jkeating@redhat.com (Jesse Keating) writes:
After repeated (heated) discussions over init scripts, I wanted to guideify my thoughts (and others) on this. Can we have some discussion over this draft and vote at next meeting?
no; %config is ok (I do not want to lose changes to /etc files silently). But I agree that there is no need to mark them as %config(noreplace).
Enrico
On Saturday 17 February 2007 06:14, Enrico Scholz wrote:
no; %config is ok (I do not want to lose changes to /etc files silently). But I agree that there is no need to mark them as %config(noreplace).
And you feel OK about other scripts on your system silently losing changes because they're outside of /etc? init script placement in /etc always seemed funny to me, these are scripts to be executed, not files to be configured. Just because they live in /etc shouldn't give them any special treatment over any other script that may live in /usr
I'd prefer if init scripts didn't live in /etc at all, or were symlinked into /etc for compat purposes, but that's a larger change than I want to push right now.
On Sat, 2007-02-17 at 09:51 -0500, Jesse Keating wrote:
On Saturday 17 February 2007 06:14, Enrico Scholz wrote:
no; %config is ok (I do not want to lose changes to /etc files silently). But I agree that there is no need to mark them as %config(noreplace).
And you feel OK about other scripts on your system silently losing changes because they're outside of /etc? init script placement in /etc always seemed funny to me, these are scripts to be executed, not files to be configured.
init scripts live in /etc, because the traditional view on them and their traditional usage is customizable/configurable scripts.
This concept is older than Linux, sysv-init, /etc/sysconfig, the LSB and the FHS. I.e. editing init scripts had been part of standard proceedures to run a system.
Since introduction of /etc/sysconfig this role has gradually lost importance, but even nowadays, there still can exist situations where resorting to it is hardly avoidable.
Ralf
On Sunday 18 February 2007 03:25, Ralf Corsepius wrote:
Since introduction of /etc/sysconfig this role has gradually lost importance, but even nowadays, there still can exist situations where resorting to it is hardly avoidable.
Is the split between config in the init script and config in a proper /etc/sysconfig file something we wish to continue, perhaps even encourage by marking such files as %config? At the very least it bothers rpmlint, but more it bothers me to have an inconsistent design for how services should be configured. We don't protect any other script which may be edited by the admin...
jkeating@redhat.com (Jesse Keating) writes:
no; %config is ok (I do not want to lose changes to /etc files silently). But I agree that there is no need to mark them as %config(noreplace).
And you feel OK about other scripts on your system silently losing changes because they're outside of /etc?
It depends on their location. When they are under /usr, I would never edit them because this location is not intended for configuration.
When they are in /etc, I expect that my changes will not be thrown away silently, because this location is intended for configuration.
Enrico
On Thu, Feb 22, 2007 at 12:23:48PM +0100, Enrico Scholz wrote:
And you feel OK about other scripts on your system silently losing changes because they're outside of /etc?
It depends on their location. When they are under /usr, I would never edit them because this location is not intended for configuration. When they are in /etc, I expect that my changes will not be thrown away silently, because this location is intended for configuration.
And further, I don't want to have to look for .rpmsave/.rpmnew files outside of /etc.
"MM" == Matthew Miller mattdm@mattdm.org writes:
MM> And further, I don't want to have to look for .rpmsave/.rpmnew MM> files outside of /etc.
Why would you look for them at all? That's what tools are for.
http://www.math.uh.edu/~tibbs/rpmchanges
Exits 1 if any .rpmnew/.rpmsave files are present. -q will give no report, -d will give you diffs.
- J<
On Thu, Feb 22, 2007 at 09:33:47AM -0600, Jason L Tibbitts III wrote:
MM> And further, I don't want to have to look for .rpmsave/.rpmnew MM> files outside of /etc. Why would you look for them at all? That's what tools are for.
Rephrase: "my tools should have to crawl the whole frickin' universe of filesystems looking for rpmnew/rpmsave files".
"MM" == Matthew Miller mattdm@mattdm.org writes:
MM> Rephrase: "my tools should have to crawl the whole frickin' MM> universe of filesystems looking for rpmnew/rpmsave files".
Just the universe of files marked as %config, as given by rpm -qac, which I thought was the whole point. After all, if you want to know the files that could potentially cause .rpmnew or .rpmsave files to be created, isn't it best to just ask rpm rather than assuming that they'll all be in a specific place?
Of course, this is pretty much offtopic for the discussion. Sorry for derailing it.
- J<
Jason L Tibbitts III schrieb:
"MM" == Matthew Miller mattdm@mattdm.org writes:
MM> And further, I don't want to have to look for .rpmsave/.rpmnew MM> files outside of /etc.
Why would you look for them at all? That's what tools are for. http://www.math.uh.edu/~tibbs/rpmchanges
I (and probably many others) have similar scripts. I'm wondering if we should trow them together, put the best one into a package (¹) and ship them in Fedora, so people don't have to reinvent the wheel over and over again.
CU thl
(¹) -- something similar to the rpmdevtools package probably
Thorsten Leemhuis wrote:
Jason L Tibbitts III schrieb:
> "MM" == Matthew Miller mattdm@mattdm.org writes:
MM> And further, I don't want to have to look for .rpmsave/.rpmnew MM> files outside of /etc.
Why would you look for them at all? That's what tools are for. http://www.math.uh.edu/~tibbs/rpmchanges
I (and probably many others) have similar scripts. I'm wondering if we should trow them together, put the best one into a package (¹) and ship them in Fedora, so people don't have to reinvent the wheel over and over again.
Maybe I'm just being dense, but aren't these files easily found with:
# updatedb # locate rpmsave # locate rpmnew
?
--Wart
Wart schrieb:
Thorsten Leemhuis wrote:
Jason L Tibbitts III schrieb:
>> "MM" == Matthew Miller mattdm@mattdm.org writes:
MM> And further, I don't want to have to look for .rpmsave/.rpmnew MM> files outside of /etc.
Why would you look for them at all? That's what tools are for. http://www.math.uh.edu/~tibbs/rpmchanges
I (and probably many others) have similar scripts. I'm wondering if we should trow them together, put the best one into a package (¹) and ship them in Fedora, so people don't have to reinvent the wheel over and over again.
Maybe I'm just being dense, but aren't these files easily found with:
# updatedb # locate rpmsave # locate rpmnew
That IMHO becomes quite annoying quickly. Thus I wrote some functions for my .bashrc that automate parts of the work -- I just uploaded them to http://www.leemhuis.info/files/fedorarpms/MISC.fdr/rpmstuff
Not sure if the stuff is complete; Warning, the stuff is grown over time and might delete all your data, kill kittens and so own. Further: there are probably much better and cleaner ways to archive the goals than the stuff I wrote. What my stuff does:
rpm_find_packages_with_corrupted_files -> finds missing, corrupted files and config files that got changed
rpmcleanup-rpmnewfile and rpmcleanup-rpmnewfiles as well as rpmcleanup-rpmsavefile and rpmcleanup-rpmsavefiles -> process rpm{new,save} files; if the md5sum is identical move the rpmnew file over for example; otherwise show a diff, ask user what to do (for example run meld to merge the files)
rpm_find_problems -> run some of above test as well as some stuff from rpmdevtools and yum-utils
I'm sure most of us have other scripts for the same and different problems. So it might be a good idea to just find the best ones for particular problems and package them up, so the problem get solved once and for all.
CU thl
On Thursday 22 February 2007, Thorsten Leemhuis wrote:
Jason L Tibbitts III schrieb:
> "MM" == Matthew Miller mattdm@mattdm.org writes:
MM> And further, I don't want to have to look for .rpmsave/.rpmnew MM> files outside of /etc.
Why would you look for them at all? That's what tools are for. http://www.math.uh.edu/~tibbs/rpmchanges
I (and probably many others) have similar scripts. I'm wondering if we should trow them together, put the best one into a package (¹) and ship them in Fedora, so people don't have to reinvent the wheel over and over again.
Everyone's welcome to suggest additions to rpmdevtools. But it would not hurt to have another similar but less development oriented package of nifty scripts around.
There's also http://fedoraproject.org/wiki/Extras/UsefulScripts
Oh, and qa-robot from ALT Linux has a bunch of useful looking things (especially rpmsodiff) that I've meant to take a look at but haven't got around to it yet, anyone interested? Some of them might require some cleanup/changes to be generally applicable outside of ALT Linux. http://www.altlinux.com/index.php?module=sisyphus&package=qa-robot
On Thu, 2007-02-22 at 18:02 +0100, Thorsten Leemhuis wrote:
Jason L Tibbitts III schrieb:
> "MM" == Matthew Miller mattdm@mattdm.org writes:
MM> And further, I don't want to have to look for .rpmsave/.rpmnew MM> files outside of /etc.
Why would you look for them at all? That's what tools are for. http://www.math.uh.edu/~tibbs/rpmchanges
I (and probably many others) have similar scripts. I'm wondering if we should trow them together, put the best one into a package (¹) and ship them in Fedora, so people don't have to reinvent the wheel over and over again.
why not put the rpmchanges mechanism in a post-transaction plugin in yum. Then it can go through and create a little report for you after any transaction.
-sv
seth vidal (skvidal@linux.duke.edu) said:
why not put the rpmchanges mechanism in a post-transaction plugin in yum. Then it can go through and create a little report for you after any transaction.
And pirut can put up a three-way diff with a Merge/Apply button. Woo.
Bill
On Thu, Feb 22, 2007 at 01:04:37PM -0500, seth vidal wrote:
why not put the rpmchanges mechanism in a post-transaction plugin in yum. Then it can go through and create a little report for you after any transaction.
Yes, please, someone, because that would reduce my todo list by one item. :)
On Friday 16 February 2007 18:00, Jesse Keating wrote:
After repeated (heated) discussions over init scripts, I wanted to guideify my thoughts (and others) on this. Can we have some discussion over this draft and vote at next meeting?
There seems to be a split as to whether or not these are config files. I could be convinced to allow them to be config (without noreplace) to preserve admin settings should they make any changes, but still allowing us to get new init files into place. If we go with this, we need to make rpmlint not balk about executables in /etc marked as config and such.
I'd still prefer that these files aren't marked as %config. Perhaps a new init system will allow for us to place these files somewhere other than /etc and really drive the point home that these files are not for configuration.
Jesse Keating wrote :
I'd still prefer that these files aren't marked as %config. Perhaps a new init system will allow for us to place these files somewhere other than /etc and really drive the point home that these files are not for configuration.
Same here. Those are scripts, not config files... and marking them as such encourages people to edit them, which is not a good idea, since those files mostly contain code and not configuration, thus a later version is much more likely to break. Not only because of changed configuration options, but because of changed interaction between the init script and what it runs (like renamed command line options for a daemon it starts, running a daemon as root which drop privileges alone or directly launching it as a user etc.).
At worst, I'd force new packages to _never_ mark them as %config and leave existing packages with bits of config in their init script as they are, clearly identifying them somewhere in the wiki if necessary, until we switch to a new init system.
Matthias
On Monday 26 February 2007, Jesse Keating wrote:
I'd still prefer that these files aren't marked as %config.
+1
Perhaps a new init system will allow for us to place these files somewhere other than /etc and really drive the point home that these files are not for configuration.
Just a FYI, LSB doesn't obviously necessarily apply to everything, but here's some related pointers, they seem to be thinking about related things for future LSB revisions.
http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generi... http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generi... http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generi...
And BTW, for what it's worth, it's /etc/init.d, not /etc/rc.d/init.d in LSB - so it might not hurt to treat /etc/init.d as the "canonical" path in Fedora wherever it is hardcoded into even though there is the symlink between the two.
Ville Skyttä wrote :
And BTW, for what it's worth, it's /etc/init.d, not /etc/rc.d/init.d in LSB - so it might not hurt to treat /etc/init.d as the "canonical" path in Fedora wherever it is hardcoded into even though there is the symlink between the two.
Argh! I could have sworn I had read the opposite somewhere, and have been changing my spec files ever since. Here too, we need to document clearly which one we should use, even though the symlink won't be removed anytime soon...
Matthias
On Tue, Feb 27, 2007 at 05:45:19PM +0100, Matthias Saou wrote:
Ville Skyttä wrote :
And BTW, for what it's worth, it's /etc/init.d, not /etc/rc.d/init.d in LSB - so it might not hurt to treat /etc/init.d as the "canonical" path in Fedora wherever it is hardcoded into even though there is the symlink between the two.
Argh! I could have sworn I had read the opposite somewhere,
Me, too. Obviously not from the LSB, I wonder where we picked that up?
and have been changing my spec files ever since. Here too, we need to document clearly which one we should use, even though the symlink won't be removed anytime soon...
Change them to use %{_initdir} and have redhat-rpm-config's maintainer fix it. :)
Axel Thimm wrote :
On Tue, Feb 27, 2007 at 05:45:19PM +0100, Matthias Saou wrote:
Ville Skyttä wrote :
And BTW, for what it's worth, it's /etc/init.d, not /etc/rc.d/init.d in LSB - so it might not hurt to treat /etc/init.d as the "canonical" path in Fedora wherever it is hardcoded into even though there is the symlink between the two.
Argh! I could have sworn I had read the opposite somewhere,
Me, too. Obviously not from the LSB, I wonder where we picked that up?
and have been changing my spec files ever since. Here too, we need to document clearly which one we should use, even though the symlink won't be removed anytime soon...
Change them to use %{_initdir} and have redhat-rpm-config's maintainer fix it. :)
I usually don't do this, but : +1
Matthias
Matthias Saou (thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said:
Argh! I could have sworn I had read the opposite somewhere, and have been changing my spec files ever since. Here too, we need to document clearly which one we should use, even though the symlink won't be removed anytime soon...
Not won't, *can't*.
If you want to remove the symlink, you need a compatibility symlink in the other way.
At that point, you have 1) a package that moves its script from /etc/rc.d/init.d -> /etc/init.d 2) a package that removes the /etc/init.d symlink and replaces it with the directory. Watch the RPM state machine....
1) Processing upgrade of package foo.. /etc/init.d/foo <- new file in new path, will write /etc/rc.d/init.d/foo <- old file in old directory, will remove 2) Pre transaction: /etc/init.d symlink removed, /etc/rc.d/init.d directory moved to /etc/init.d. /etc/rc.d/init.d symlink created 3) Transaction is run /etc/init.d/foo is written /etc/rc.d/init.d/foo is removed - Oops, that follows the symlink and we remove the file we just wrote.
Bill
Bill Nottingham wrote :
Matthias Saou (thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said:
Argh! I could have sworn I had read the opposite somewhere, and have been changing my spec files ever since. Here too, we need to document clearly which one we should use, even though the symlink won't be removed anytime soon...
Not won't, *can't*.
If you want to remove the symlink, you need a compatibility symlink in the other way.
Hehe, but you're thinking in terms of today's rpm. Discussing stuff with Jeff at the FOSDEM this week-end, he already has a way of dealing with this well known limitation, which (from what I've understood) would basically be a "pre everything" approach. A similar "post everything" approach and a little magic could also nicely solve the icon caches, mime types, menus etc. performance problems.
Which is why I didn't say "never", but "anytime soon" ;-)
Matthias
Matthias Saou (thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said:
Hehe, but you're thinking in terms of today's rpm. Discussing stuff with Jeff at the FOSDEM this week-end, he already has a way of dealing with this well known limitation, which (from what I've understood) would basically be a "pre everything" approach. A similar "post everything" approach and a little magic could also nicely solve the icon caches, mime types, menus etc. performance problems.
Well, the approach I posted was what happens *with* pre-transaction syscalls, as they were implemented by Jeff. What needs to happen is that the pre-transaction stuff needs to run before the transaction is even computed, which makes it messy.
Bill
Bill Nottingham wrote :
Matthias Saou (thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said:
Hehe, but you're thinking in terms of today's rpm. Discussing stuff with Jeff at the FOSDEM this week-end, he already has a way of dealing with this well known limitation, which (from what I've understood) would basically be a "pre everything" approach. A similar "post everything" approach and a little magic could also nicely solve the icon caches, mime types, menus etc. performance problems.
Well, the approach I posted was what happens *with* pre-transaction syscalls, as they were implemented by Jeff. What needs to happen is that the pre-transaction stuff needs to run before the transaction is even computed, which makes it messy.
Not "pre transaction", but "pre everything" indeed. He mentioned that the idea was to fix exactly this scenario (from what I understood), but I didn't catch the details.
Anyway, "not anytime soon" still stands, and even includes "never" ;-)
Matthias
packaging@lists.fedoraproject.org