On Thu, 27 Jan 2005 14:46:01 -0500, Jeff Spaleta wrote: > On Thu, 27 Jan 2005 12:49:12 -0500, Toshio <toshio@xxxxxxxxxxxxxxx> wrote: > > I'm also still waiting to see why the current de facto scheme of: > > current = libname > > previous = libname[Version] > > > > is _compellingly_ wrong... Perhaps there just needs to be a summary of > > Pros and Cons so we can see the tradeoffs. > > If i understand the argument that people are making... is that doing > it this way... is a burden on 3rd party packagers who have to try to > predict when and if Core is going to introduce a libname[Version] for > previous versions. Whenever that happens - when a Core package is renamed like this - the 3rd party packagers need to update their spec files to make them buildrequire libname[Version]-devel instead. Similarly, when the soname's major library version is put into the package name always, the Core packagers and everyone else, who wants to build rpms with the new library, would need to update the build requirements in all spec files when the major library version is increased. And what does the rule look like with packages which contain multiple libraries with different major versions? > And by association also a burden on users who are trying to use > applications from outside of current Core that still need the older > libs for applications until a 3rd party is able to rebuild a package > with the older libs or the application developers retool to support > the new library. That I don't see. Thanks to automatic dependencies on versioned sonames, the user doesn't need to know where libfoo.so.3 comes from, i.e. whether it is to be found in package libfoo3-3.0.1-1 or libfoo-3.0.3-1.
