Excerpts from BJ Dierkes's message of Fri Jan 13 21:09:40 +0100 2012: > > On Jan 13, 2012, at 2:11 AM, Henrik Ingo wrote: > > > On Fri, Jan 13, 2012 at 4:00 AM, BJ Dierkes > > <[email protected]> wrote: > >> Where the Provides is at least '1' higher than the conflict. That said, > >> this does not fly in Fedora… as there are explicit package guidelines that > >> state that nothing in Fedora/EPEL can hard conflict with another package. > >> > > > > It took me a while to understand what this means, but seems this is > > perfectly ok also with our current way of doing things. This just > > means that Fedora/EPEL will only stick to a specific Drizzle version > > per Fedora/EPEL release. It's what I expect all distros to do anyway. > > > > So for instance if Fedora 14 had drizzle7, it will never have > > drizzle7.1. Next version of Fedora (is it 16?) would possibly choose > > drizzle7.1 and never ship drizzle7. EPEL would do the same, until > > drizzle is included in RHEL after which EPEL cannot contain any > > drizzle version. It seems all of this is quite ok (and would be the > > case also if we changed name, version to be drizzle-7.1). > > > > I understand the reasoning behind doing the versioning this way. Buy I have > to tell you, going this route makes quite a headache for distros.. at least > with Fedora in mind. This is because every package in Fedora must be named > based on the source. Therefore, drizzle7 in Fedora is a complete separate > package (git repo, package in pkgdb, etc) than drizzle7.1. So once > drizzle7.1 was destined for Fedora, the following would have to happen: > > * drizzle7 would have to be EOL'd > * drizzle7.1 would have to go through a package review > * drizzle7.1 branches (git repo, package in pkgdb, etc) would all need to be > requested and created by Fedora admins > * Everything that requires drizzle7 would have to be updated/auditted/etc to > avoid breaking anything > > > On the last note, if the package just 'Requires: drizzle' then there isn't a > problem… but new package maintainers may not know that… and would do what > everyone else does which is to Require the actual package name. As a Fedora > maintainer… this type of upstream model would really drive me crazy and would > push me toward not wanting to maintain the packages.
For MySQL, in Debian, this is actually the preferred approach. Passing the NEW queue every few years when MySQL comes out with a new version (we just did this with mysql-5.5) isn't that much burden. Meanwhile we get a review for license compliance and obvious packaging policy violations. The biggest reason is to allow for an easy transition to the new release, so we can keep components that are still required by some packages while the new version is brought in. Any dependencies should not be on 'drizzle7' or 'drizzle7.1' but on 'drizzle-server' or 'drizzle-client', which would simply be superseded each time a new version is imported into Fedora. I don't mean to imply that you should do this in Fedora, but its worth noting that this model works rather well for Debian (and subsequently, for Ubuntu). _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
