Attachment 313810 Details for Bug 453109 – IRC log

IRC log

irc.log (text/x-log), 7.79 KB, created by Miroslav Suchý on 2008-08-08 14:27:19 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Miroslav Suchý

Created: 2008-08-08 14:27:19 UTC

Size: 7.79 KB

patch

obsolete

>[15:07] <msuchy> stahnma: https://bugzilla.redhat.com/show_bug.cgi?id=453109 few question about
>[15:08] <stahnma> sure
>[15:08] <msuchy> stahnma: but first thx, that you grap this review :)
>[15:08] <msuchy> stahnma: 
>[15:08] <msuchy> I'm not sure if any documentation is sane for this packages. Some
>[15:08] <msuchy> documentation is provided in other packages. Do you really insist on this?
>[15:08] <stahnma> no, it was just a qestion
>[15:09] <stahnma> I actually was wondering why this couldn't be combined with another NOCpulse package
>[15:09] <stahnma> I mean, it's only a useradd (basically)
>[15:09] <stahnma> the obsoletes/provides is a must
>[15:09] <msuchy> stahnma: probably can, but i want to make as less changes as possible
>[15:10] <stahnma> the code vs content, I sent a question to a packaging committee guy on that
>[15:10] <stahnma> because I am not quite sure how that works
>[15:10] <msuchy> stahnma: about obsoletes/provides:
>[15:10] <stahnma> and I am not sure how you license a user ;)
>[15:10] <msuchy> Since I dramaticaly change nocpulse packages to confirm Fedora guidelines
>[15:10] <msuchy> (like moving paths to confirm LSB) the packages *will not* be backward
>[15:10] <msuchy> compatible, therefore I'm not going to put there Provides:
>[15:11] <stahnma> well, then it probably shouldn't obsolete it either right?
>[15:11] <stahnma> it's just new?
>[15:11] <msuchy> hmm, well since I add there the logrotate script it will have the code (or content or whatever)
>[15:11] <stahnma> dgilmore: opinoins on that?
>[15:11] <stahnma> dgilmore: is an excellent packaging resource.  You're lucky you got him now ;)
>[15:12] <stahnma> msuchy: good point
>[15:12] <msuchy> stahnma: no, you *can* upgrade from older nocpulse packages to this new. But you must upgrade all. you can not mix it.
>[15:12] <stahnma> I think that'd be ok.  Not ideal for the whole thing, but ok
>[15:12] <stahnma> I would like a second opinion from somebody
>[15:12] <stahnma> ok
>[15:12] <stahnma> msuchy: It's really close to ready either way
>[15:13] * stahnma has to run out to a meeting. 
>[15:13] <msuchy> stahnma: btw. I'm going to rename that package, becouse rpmlint yell that logrotate should be named %{name} and have /etc/logrotate.d/nocpulse-user is odd.
>[15:14] <msuchy> stahnma: I'm going to rename it to nocpulse-common
>[15:14] <msuchy> stahnma: ok, I'll post it to BZ.
>[15:14] <dgilmore> stahnma: if all a package does is add a user id question why the package exists at all
>[15:15] <dgilmore> msuchy: you really should provide and obsolete  the older packages
>[15:15] <dgilmore> msuchy: provide a migration script  like the fedora-ds guys did
>[15:15] <msuchy> dgilmore: becouse there is dozen other packages which assume that this user exist
>[15:15] <dgilmore> msuchy: thats really not a good enough reason
>[15:16] <dgilmore> msuchy: find the first package you need installed that needs the user and add it there
>[15:16] <dgilmore> then Requires(pre) that package
>[15:17] <dgilmore> msuchy: or you can add to each package a check for the user and create it if it doesnt exist
>[15:17] <msuchy> dgilmore: which is quite silly, the first is much better and doable (merge with nocpulse-config)
>[15:19] <msuchy> dgilmore: I just have bad feeling that I change structure of nocpulse "just" because we want it to put in fedora. This will not be nocpulse, but nocpulse-ng :)
>
>[15:22] <dgilmore> msuchy: its not at all silly
>[15:23] <dgilmore> msuchy: following FHS is a very good thing.
>[15:23] <dgilmore> the fedora-ds guys are much happier now that they are following it
>[15:23] <jmrodri> dgilmore, FHS?
>[15:24] <msuchy> Filesystem Hierarchy Standard
>[15:24] <jmrodri> ah
>[15:24] <dgilmore> jmrodri: one of the issues that msuchy had was that he did not want to put Provides: in because he had to follow FHS
>[15:25] <msuchy> dgilmore: the problem is that I have absolutly no idea if it will work if I put there the provides
>[15:26] <msuchy> dgilmore: it can, but it can not too.
>[15:26] <msuchy> dgilmore: and I have no enough resource to do qa.
>[15:28] <msuchy> dgilmore: or else. I'm quite sure it will not work. If package A expect path /opt/home and package AA (which obsolete A) change this path to /var/lib/A then package B, which require A will not work if I upgrade A to AA
>[15:29] <msuchy> because B use /opt/home, which no longer exist
>[15:31] <msuchy> dgilmore: I agree that FHS is good thing, but old nocpulse is crap and mix of old and new nocpulse packages will simply not work.
>[15:32] <dgilmore> msuchy: you need to document and provide a migration script.  or say that you cant upgrade and need to do a clean install
>[15:35] <msuchy> dgilmore: migration will be easy, just yum upgrade and that it is. you just can not do yum upgrade nocpulse-common (which change path to of config files) and expect that all the other old packages will still work.
>[15:35] <dgoodwin> dgilmore: thx
>[15:35] <dgilmore> dgoodwin: i rsync from mirrors2.kernel.org
>[15:36] <msuchy> dgilmore: and if I put there the Provides: it will be possible to do this scenario.
>[15:36] <dgilmore> msuchy: so your Provides and Obsoletes will cover that and make sure the upgrade happens wholsale
>[15:37] <dgilmore> msuchy: you will Obsolete the old version and bellow and provide a higher version
>[15:38] <msuchy> dgilmore: hmm I'll describe one scenario...
>[15:43] <msuchy> dgilmore: we have NP-common-1.0 and package A which require NP-common (no specific version). I change NP-common to  nocpulse-common-2.0, change ther path to config (which use package A) and put there Obsoletes: NP-common <=1.0  and  Provides: NP-common =2.0. Than I can do yum install nocpulse-common and yum allow it, but package A will not work
>[15:44] <msuchy> dgilmore: If I do not put there the Provides: it will not allow the upgrade, unless I have new version of A.
>[15:45] <msuchy> dgilmore: or you have better idea what to put in Provides to avoid this scenario?
>[15:45] <msuchy> dgilmore: maybe I'm seeing it in wrong light.
>[15:46] <dgilmore> you will need to have a new version od package A that has a Requires NP-common >= 2.0
>[15:47] <msuchy> dgilmore: yeah, agree. But if user is stupid enought to upgrade only that package rpm will allow it.
>[15:47] <dgilmore> msuchy: its certainly not perfect.  but you must work withini the packaging guidelines.  they are applicable to fedora as well as RHEL at least AFAIK  and they should be applicable for all add on packages also
>
>[15:49] <msuchy> dgilmore: can you point me to part of guidelines which say, that each obsoletes should have provides?
>[15:52] <msuchy> dgilmore: rpmlint -i say:
>[15:52] <msuchy> If a package is obsoleted by a compatible replacement, the obsoleted package 
>[15:52] <msuchy> must also be provided in order to provide clean upgrade paths and not cause 
>[15:52] <msuchy> unnecessary dependency breakage.  If the obsoleting package is not a compatible 
>[15:52] <msuchy> replacement for the old one, leave out the provides.
>[15:52] <msuchy> * compatible*
>[15:53] <msuchy> I'm saying that the new version is not compatible
>[15:53] <dgilmore> msuchy: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages
>[15:54] <dgilmore> msuchy: in which case i think its appropriate to document the incompatabilites  and if need be provide a migration script
>[15:54] <msuchy> dgilmore: If a package supersedes/replaces an existing package without being a compatible enough replacement as defined in above, use only the Obsoletes from above.
>[15:55] <msuchy> 4th paragraph
>[15:55] <dgilmore> msuchy: you really cant provide for the user doing something like only upgrading half the stack.  if they do then they get the pieces
>[15:56] <msuchy> dgilmore: they should not get incompatible piece unless they --force
>[15:57] <msuchy> dgilmore: ok ,I can put that in documentation
>[15:57] <msuchy> dgilmore: something like: This package is not backward compatible with NP-foo from RHN satellite product
>[15:58] <dgilmore> msuchy: yep

Actions: View

Attachments on bug 453109: 313810