Jos Vos wrote: $ rpm -qp --provides libkexif-0.2.1-0.fdr.1.i386.rpm libkexif.so.1 libkexif = 0:0.2.1-0.fdr.1 $ sudo rpm -Uvh libkexif-0.2.1-0.fdr.1.i386.rpm libkexif-devel-0.2.1-0.fdr.1.i386.rpm erreur: Dépendances requises: libkexif.so.0 est nécessaire pour (déjà installé) kipi-plugins-0.1-0.fdr.0.1.beta1 libkexif.so.0 est nécessaire pour (déjà installé) digikam-0.7-0.fdr.1 libkexif.so.0 est nécessaire pour (déjà installé) showimg-0.9.4.1-0.fdr.1.2 My point is that if the rpm name contained the soname, version 0.1 and version 0.2 could be installed at the same time, and I would not have to update all the packages depending on it immediatly. With only 3 applications, it's not a very big problem, but it could be a lot worse with a more important library. Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info Passwords are like underwear. You shouldn't leave them out where people can see them. You should change them regularly. And you shouldn't loan them out to strangers.

[snip] Unrelated, but I have to ask: what is the purpose of defining name/version/release like this: %define name gtkmm %define version 1.2.4 %define release 1mdk and then: Name: %{name} Version: %{version} Release: %{release} I've seen it in a number of spec files. And please no "Well, Mandrake sucks!". /Peter

On Mon, 2005-01-24 at 11:42 +0100, Ralf Ertzinger wrote: Another way to achieve this is to... *drum roll*... place those three real "Name:, Version:, Release:" lines at the very top of the spec file! ;) See eg. the spec templates in fedora-rpmdevtools in pre- extras.

Peter Backlund wrote: The is the "Marc Ewing School of Packaging" style, adopted by GNOME, and one of the first attempts at generating *.spec files automagically from scripts, that still flourishes (like a milk weed does. There is no reason whatsoever to use %define's for name/version/release however. MDK is RHEL optimized for the i686! Perhaps MDK would be willing to tak over hosting of the endless optimization discussion from fedora-devel too. 73 de Jeff

On Mon, 24 Jan 2005, Peter Backlund wrote: I don't see the point of defining name/version/release *twice*. ?? Also, this reply didn't really answer the original question, which was, how to release rpm's to provide multiple versions of the same shared library. -- Rex

Le lundi 24 janvier 2005 à 11:34 +0100, Aurelien Bompard a écrit : This is done when needed. Example for FC3 : gtkhtml2-2.6.2-1.i386.rpm ; gtkhtml3-3.3.2-3.i386.rpm btw : [fmatias@one i386]$ rpm -q --provides -p gtkhtml2-2.6.2-1.i386.rpm libgtkhtml-2.so.0 <=== gtkhtml2 = 2.6.2-1 [fmatias@one i386]$ rpm -q --provides -p gtkhtml3-3.3.2-3.i386.rpm libgnome-gtkhtml-editor-3.1.so libgtkhtml-3.1.so.11 <=== gtkhtml3 = 3.3.2-3 Other packages must use "Requires : libgtkhtml-2.so" and not "libgtkhtml3" or "gtkhtml3".

Jeff Johnson wrote: Of course not :) Shared libraries are a different problem however, and it may be nice to install different versions at the same time. Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info It is by caffeine alone that I set my mind in motion. It is by the beans of java that the thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone that I set my mind in motion.

Jeff Johnson wrote: Really ? How could I install two different versions of the same library without changing the package name then ? Thanks Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info Unix IS user-friendly. It is just very picky about who his friends are.

Jeff Johnson wrote: Yeah OK. How about something that would be understood by depsolvers then ? This must be a common problem, isn't it ? What do you do when an important library changes its soname in the next version ? Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin

Phil Knirsch wrote: Well, I think that adding the soname to the rpm name could help with that: dependant apps will still require the old package, until they are rebuilt and automatically require the new package. The only con I see is that there may be libraries around which are not required anymore. But that can easily be solved. I think that this problem should be all the more adressed that Fedora is becoming a community-open distribution: the maintainer of the library is not necessarily the maintainer of the dependant apps. There must be an easy upgrade path for those situations. Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info No, I coded it crappily on purpose, just so that I could say "There's plenty of room for optimization."

On Mon, 24 Jan 2005, Nicolas Mailhot wrote: ... Agreed. Avoid the extra hassle of multiply installed libfoo.so's unless absolutely necessary. Otherwise, it's added complexity and bloat for relatively little gain. -- Rex

On Mon, 24 Jan 2005 09:15:14 -0500, Sean Middleditch <elanthis(a)awesomeplay.com&gt; wrote: A third part website is packaging libbar.so.2 in a package of the same package name as Feodora's libbar.so.1? Why would a third party site do that? Unless the intention was to replace the Fedora package? Isn't this an example of the care 3rd party packagers should be taking to make sure their packages work well with Core? And I might add.. that while users and admins.. might want to install many other apps from anywhere on the net that the find them... this is not necessarily advisable behavior. You continue to cater to this sort of thing and you will end up with people install very old libraries that are no longer being maintained so that they can install very old applications that are no longer being maintained and could have unresolved but well understood security problems. I'm really not sure its in anyones best interest to make it really drop-dead easy to install unmaintained software that might be expoitable simply because the package was created in 2000. -jef

On Mon, 24 Jan 2005 10:02:52 -0500, Jeff Spaleta wrote: Wow - 2000 is only 5 years ago guys. There are *lots* of people still running programs designed for Windows 95, which is now 10 years old! Face it: people will run the software they want. If you make it difficult or annoying for them out of a misguided sense that security-through-obnoxiousness is OK, they'll just use Windows which doesn't do much for security at all but at least makes it easy for the user to achieve their goal. The best solution is for libraries to not break backwards compatibility every other week, that way security fixes are magically present even for 5 year old apps. Seriously, 5 years is really nothing, it's all about mindset. thanks -mike

On Mon, 2005-01-24 at 14:57 -0500, Jeff Spaleta wrote: You're not going to stop anyone from installing old libraries; you're just stopping people from running modern applications that depend on last week's libraries. A user's system basically becomes impossible to upgrade and impossible to install new software on until the entire Open Source world recompiles all their packages for the new library. If two libraries could be installed at once the user wouldn't be trapped during the transition - they could just get on with life as normal. Is Fedora supposed to be an exercise in speedy RPM rebuilding, or an operating system? Oh, but they will, eventually. Looks like Fedora added a gtk2 package instead of just updating the gtk package to the 2.x series. You guys did great with gtk, so what's the problem with other packages? gtk1 is completely unmaintained and not only installed on many users machines, but even shipped with Fedora. ;-) Unfortunately, Fedora seems to be moving towards relying on huge massive centralization of software packages to resolve broken packaging and lazy development. If it isn't shipped with Fedora Core/Extras, users aren't allowed to use it?

On Mon, 2005-01-24 at 22:14 +0100, Féliciano Matias wrote: "capabilities equivalent to competing operating systems"... does that not include "install stuff" for some reason? The Open Source community is pretty good these days about using sonames properly. It's silly to have packages go and break all that effort. Sonames exist for a reason. Neither of which have I ever asked for, nor would I. The number of incredibly absurd ways people seem to interpret "let's not break stuff pointlessly" is constantly amazing, and starting to become rather dumbfounding.

On Mon, 24 Jan 2005 14:57:57 -0500, Jeff Spaleta wrote: I'll skip the "backwards compatibility == viruses" stuff as it really isn't relevant here and doesn't stand up to close inspection anyway (hint: is it useful to prevent people who rely on a particular program from getting *any* security updates at all, because one breaks their program? no other desktop OS vendor has said yes here). Since when is this just about "rebuilding" stuff? Do you think apps are magically ported to GTK+ 2 by running gcc on them? What about OpenSSL? This is not simply a matter of running gcc or rebuilding packages. It's a much deeper issue. Not in the slightest, it's fundamental to packaging issues. Why is Fedora including unstable libraries as discrete packages at all? Why not just statically link them into the packages that need them? Yes I'm aware of the disadvantages of static linking. Are you aware of the disadvantages of dynamic linking? Outside of the Linux community (ie, in the *desktop world*) the current rate of instability is simply unacceptable. Why do you think Red Hat make money by selling what is essentially an old version of Fedora? <sigh> I don't know why I bother, really, Sean is quite right - the number of ways people justify massive "platform" (haha) instability to themselves is astonishing. I should keep a note of them all or something. This sort of thing keeps coming up again and again because it causes users *pain*, and each time it does people write it off as "not our problem", "unfixable", "only proprietary software needs that" or "DO YOU HATE INNOVATION!?!" type crap. thanks -mike

On Mon, 24 Jan 2005 23:08:47 +0100, Axel Thimm <Axel.Thimm(a)atrpms.net&gt; wrote: But is there clean way to indicate to a user that an older version of the library is no longer being maintained and has "expired" and won't be getting any security updates? This is not not just an issue of finding the unused libs. An unmaintained library package could still be in use by an application. How do you make the admin aware that a library package they are using is no longer being maintained so they can review whether or not to keep it and the applications using it installed? Unless there is a mechanism by which admins are informed of an expiring library so they can make an informed decision, i don't feel its worthwhile to encourage the accumulation of older libraries at all. -jef

On Mon, 24 Jan 2005 23:40:43 +0100, Axel Thimm <Axel.Thimm(a)atrpms.net&gt; wrote: keeping the package the same name... regardless of the soname means on distro upgrade the old version gets removed. This works to expire an older library package but breaks externally build apps that need the old library. You want to keep those things from breaking and I want to expired libs off the system. I would prefer to use the sonames in the packages as sparingly as possible.. to minimize the amount of deprecated libraries on system...until there is a solution to the larger question of how expiring of a package is suppose to work. -jef

On Tue, 25 Jan 2005 00:21:13 +0100, Axel Thimm <Axel.Thimm(a)atrpms.net&gt; wrote: no.. you missed my point... expiring because nothing depends on them is NOT what im talking about. I'm talking about expiring a package because the package author is no longer maintaining that version of the library regardless of whether an externally built application from somewhere else are still using that version of the library. If i haven't made my point clear enough, I apologize. Your leaf detection mechanism is not going to address this issue. -jef

On Mon, 24 Jan 2005 19:54:30 -0500 (EST), Sean <seanlkml(a)sympatico.ca&gt; wrote: I'm explaining a situation that the current naming method handles better than the proposed per soname does. I'm not arguing for any policy change at all, you are. if you want to argue for a policy change I would hope that you are open minded enough to keep other issues other than your primary concern in mind. The soname in package policy you would like to see for all packages... will negatively impact the aspect of packaging I bring up compared to the current method of doing the per sonaming on an as needed basis. Packaging policy is a complex issue, and while you would like to focus on one aspect and build a policy that makes that one aspect easier to deal with... it has consequences for other aspects of packaging. I'd love a perfect solution that everyone will like that solves all problems, but in the meantime I'm not horribly upset with the 'as needed' policy as a compromise no one likes and solves no problems well. How about we backup... and we imagine reasons why historically the per soname scheme hasn't been used by and large by Red Hat... perhaps if we did that there will be other aspects of packaging besides the one I bring up that constrain your soname solution. -jef"but its much more fun to think Red Hat packagers are just stupid or malicious and have chosen a package naming scheme delibrately to irk other people"spaleta

okay I'm going to throw out some silly ideas for gathering info on the 'age' of a package. 1. panu's leaf code - I've used it - it does turn up things that nothing depends on and does it nicely. 2. look for shared objects in the filelists of the things turned up in 1 3. look for packages that have been untouched in > than N days/months/years 4. look for packages whose build date is many many months ago. None of these will get rid of every case - but it will help us identify odd situations and left-over cruft. thoughts? -sv

Obsoletes should be used when a package changes name. Not when someone thinks a new version gets rid of an old version. -sv

On Tue, 25 Jan 2005, Aurelien Bompard wrote: I depends on your definition of Obsoletes. In my mind, it could be used for either purpose. -- Rex

On Tue, 25 Jan 2005 08:53:17 -0500, seth vidal wrote: Where are such strict semantics of the "Obsoletes" field defined? Isn't it rather free to use? As in "we don't need that package any longer, it's obsolete and can be erased"? If, for instance, functionality of one package is supplied by another package, that's not a rename, but a relocation of package capabilities. Package "foo" would "Obsoletes: bar <= 1.0". If an old library API/ABI is not used anymore and hence considered obsolete, a new version of the library could "Obsolete: libfoo <= 0.9" just fine.

On Tue, January 25, 2005 10:11 am, seth vidal said: Is there a good reason it shouldn't be used to mark packages as obsoleting others? If so, what is it? Sean

On Tue, 25 Jan 2005 10:21:56 -0500, seth vidal wrote: We don't. This is still about libfoo obsoletes libfoo10 isn't it?

On Tue, Jan 25, 2005 at 10:56:17AM -0500, Jeff Johnson wrote: Unless it is provided by the same package like the usual Provides: foo Obsoletes: foo [<= ...] But it is even worse, if two different packages provide/obsolete foo, now they obsolete each-other, too. That's unexpected behaviour IMHO. Furthermore Provides: currently also effectively implies Obsoletes, but only for non-virtual Provides (e.g. a package name). That's the bug^Wfeature that has troubled PyVault and others so much. So I agree with Jeff. There is a high need for strict definitions of what these semantics express and what rpm (and thus rpm-based resolvers) should do with it. -- Axel.Thimm at ATrpms.net

Harald Hoyer wrote: I'd be very happy to do that, but I'd like to know : is this the scheme Red Hat is going to be moving to ? Soname in the package name and a Provides : shared-library-package in the spec file ? Do we agree on this ? I also think it is a great solution, which adresses correctly all the major issues raised here. I'd be very happy to see it become a packaging policy. Thanks Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -- Rich Cook

On Thu, 27 Jan 2005 12:49:12 -0500, Toshio <toshio(a)tiki-lounge.com&gt; wrote: 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. 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. My counter argument is that doing it this way historically has provided a mechanism by which Core(and rhl before it) explicitly and delibrately chooses to expire older libraries that Core is no longer maintaining and is no longer needed by anything inside Core. Another argument which has been made for continuing in this fashion is that standardizing on using sonames in all library packages potentially lowers the bar to backward-compatibility cruft. Such libraries would linger in an unknown maintainership state and be difficult to drop at any point because there will always be users who are using legacy application that needs that legacy library. -jef

On Thu, 27 Jan 2005 21:52:18 +0100, Aurelien Bompard <gauret(a)free.fr&gt; wrote: I dont think the shared-library-package provides solves the cruft problem from the project perspective. From the user perpective yes the provides hack will be a somewhat useful mechanism for users/admins to cull cruft from their boxes. But i don't think thats what Ville had in mind when making the argument. I think Ville was talking about how the project as a whole prevents itself from accumulating layers and layers of library cruft that become harder and harder to maintain as time goes by because there is less and less upstream interest in maintaining the aging codebase. Its easy to package up an old library and offer it.. it gets harder and harder to 'maintain' such a package with critical and security related patches if the upstream development interest has dried out. I think Ville's arguement is aimed at making sure that whatever policy Core is using doesn't encourage the accumulation of difficult to maintain legacy libraries for which users are expecting to be able to be maintained at a high standard. Again these solutions have focused on the user's perspective of how to garbage collect unused libraries. That is not the crux of my concern. I've been trying to talk about a mechanism by which the package authors can expire a library.. thus notifying ALL users of that particular package that the author is no longer going to be providing any maintence for that library. And when the package authors have decided to expire the library.. the secure thing to do is to remove that library from the system regardless of what applications are still using it, until a new package author can be found for that library who is willing to 'maintain' the library. This is what effectively happens when core drops libfoo.so.1 from package libfoo and adds libfoo.so.2 instead. When the installer is used to upgrade to the new Core, any package that depends on that old libfoo.so.1 library breaks or gets removed. Sucks for the user that doesn't care about running vulnerable code.... sucks marginally less for a user who wants to make sure they aren't going to be opening themselves up to a future vulnerability that won't get patched with an update. The garbage collecting ideas address a different problem altogether than the 'expiration' issue i see the current core naming scheme being implicitly used for in some situations. Every if you garbage collected.. you still don't have a clue about whether the original author is going to be issuing updates anymore for a libfoo1 package that you are still using for a number of applications in the soname in packagename scheme. Keeping the libfoo package name across soname versions implicitly defines an enforced expiration policy by the package author. -jef

On Thu, 27 Jan 2005 19:08:36 -0500 (EST), Sean <seanlkml(a)sympatico.ca&gt; wrote: Feel free to read any intent you feel you need to into what I'm saying. I'm looking at what I see as the historical 'implied' usage of library naming scheme in use. I'd love to be told I am wrong, and that this hasn't been a reason why the particular naming scheme has been used in the past. But if this has been an reason in the past.. its worth noting and trying to understand why it was deemed important before. You feel this isn't an important issue... fine... your opinion. But I want to make sure that everyone in this discussion has a competent understanding of WHY we have the current naming scheme... before myopic decisions are made with regard to what to do in the future. You don't think this is an important issue.. fine... but your opinion of its importance doesn't change whether or not the issue of 'expiring' is a reason why the naming scheme is currently in use. Regardless of what you think the correct path forward is... i think its vitally important to have an understanding of WHY the current naming scheme is being used to underpin any competent discussion about how to change it. I'm not sure any of the vocal proponents of the naming policy change have an understanding of why the current naming scheme exists. Once everyone has a good feel for why the current naming scheme exists... maybe... sort of depends on whether the 'right' people's priorities line up with yours. I'm not even sure the 'right' people are even reading this thread any more so any further discussion may very well be moot. -jef"playing the jester to the moot court"spaleta -jef

Jeff Spaleta wrote: I see your point. OK, this is a dirty hack, but could we have, say, the fedora-release package "Conflict" with expiring package libraries ? (Told you it was dirty...) My point is: could we use our existing packages and the Conflicts (or another one) mechanism to expire a library ? I really think that this problem is worth taking some time to solve it. Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info "Never trust a computer you can't throw out a window." -- Steve Wozniak

Sean wrote: I think Jeff wants the garbage-collecting process to be initiated by the distribution, and not to depend on the user running a garbage collector by himself. Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info "As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours ; and this we should do freely and generously." -- Benjamin Franklin

On Mon, 31 Jan 2005 06:18:25 -0500 (EST), Sean <seanlkml(a)sympatico.ca&gt; wrote: Yuo keep missing my point. I think some packagers have been worrying about this all along and is one of the reason why soname in packagename hasnt been the norm for Red Hat ever. Whether or not you think its a corner case.. while a fascinating bit of information for me to know... doesn't change whether or not this issue i bring has been an important factor in the past for packagers who are not using the soname-in-packagename model. And if it has been an important factor in the past... i'd like to know what has changed. -jef

On Mon, January 31, 2005 8:35 am, Jeff Spaleta said: Jeff, You keep missing the point. Just because you don't think it's a corner case, while a fascinating bit of information doesn't mean it's important factor for anyone. You continue to miss that people have already offered workable solutions. Anyway, you've failed to show it has ever been an important factor in the past or would even be one in the future. Nothing has changed. Sean

On Mon, January 31, 2005 11:30 am, Jeff Spaleta said: -- I don't think i've made a judgement as to whether or not this is a corner case. What I care about is understanding why the current naming scheme was chosen so we can have informed debate. So far no one has told me my obvservations are incorrect. Whether or not this historical usage is an important consideration is a discussion that comes after we have an understanding of what the historical usages are. Without an understanding of why the current naming scheme was chosen, and how its been used.. we are not in a solid position to evaluate a change in policy. I challenge you... as a proponent of change.. to give us your understanding as to why the current naming policy is in place. -- I'm just a proponent of you coming to terms with the fact that your instinct to become involved in every single thread just wasn't helpful or insightful this time. Perhaps there's a chance... however small... that you might actually be .... gasp .... wrong. Really, a viable option was even presented in this thread to deal with your concern. But if you have no historical insight or judgement of your own on the matter, let someone who does pipe in if they think its important, instead of sidetracking the conversation into oblivion. Not everything has to be explained to _you_ before proceeding. TTN, Sean

On Fri, 28 Jan 2005, Michael Schwendt wrote: I thought the proposal included that each package include Provides: libname = %version or was that also determined to be problematic? -- Rex

On Thu, Jan 27, 2005 at 08:45:47PM -0600, Rex Dieter wrote: That would be a way, but I would be less intrusive right now. Just use foo-devel and have foo-devel require libfoo<major>. I.e. the libfoo<major> package is nowhere explicitly requested outside the package itself. That way all packages can be refactored in asynchronous time w/o changing dependencies of other packages. Example: old: foo-1.2.3-4.src.rpm generates foo-1.2.3-4.i386.rpm foo-devel-1.2.3-4.i386.rpm new: foo-1.2.3-4.src.rpm generates foo-1.2.3-4.i386.rpm libfoo5-1.2.3-4.i386.rpm foo-devel-1.2.3-4.i386.rpm -- Axel.Thimm at ATrpms.net

On Tue, 25 Jan 2005 02:02:51 +0100, Axel Thimm <Axel.Thimm(a)atrpms.net&gt; wrote: On the other hand keeping packages the same name when an older soname expires handles the case i bring up exceedingly well. package libfoo in fc3 provides libfoo.so.1 package libfoo in fc4 provides libfoo.so.2. Upgrades from fc3 to fc4 and libfoo.so.1 is no longer on the system. Works like a charm at keeping unmaintained library versions off the system. It works so well in fact.. that it almost seems like it was a design goal for naming library packages without sonames. And thats the point I'm trying to make. Moving to a per soname when its absolutely not needed has consquences for other aspects of packaging. As soon as the proponents for a soname-in-the-rpmname have a workable proposed solution to the problem I bring up, I'll gladly stop bringing it up. -jef

Axel Thimm wrote: Very nice idea!

Nicolas Mailhot wrote: I did not know, is it possible to have a tool find the rpms that no rpms depend on, and ask to remove them ? For this task, Debian has something called deborphan (which might do more than that) and Mandrake has "urpm-find-leaves" IIRC. Maybe that could be a start. Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info A Black Hole is where God divided by zero.

On Mon, 24 Jan 2005, Aurelien Bompard wrote: Check out this for example: http://lists.freshrpms.net/pipermail/freshrpms-list/2003-March/003391.html - Panu -

Hi. Aurelien Bompard <gauret(a)free.fr&gt; wrote: The problem with this is that RPM does not indicate whether a package has "end user value" (a command line or GUI program, or a daemon), or is just a support library needed by said end user programs, which can be removed if not needed by anyone. -- <@Zeroth>Frickelsoftware! <@pretec>Kommunistische! <@Zeroth>Von bekifften, stinkenden, Langzeitlanghaarstudenten in Bastelbudenkellern programmiert -- #lug-kiel, Oct 13 2004

On Mon, 2005-01-24 at 15:16 +0100, Aurelien Bompard wrote: Run the script with -a option to see why only packages with .so files are considered: without it there are far too many false positives for the output to be useful (never mind dangerous stuff like 'grub' listed as unneeded). One can probably improve the heuristics somewhat but it'll always be just a checklist of *potentially* unneeded stuff. - Panu -

On Mon, 2005-01-24 at 15:11 +0100, Ralf Ertzinger wrote: Though you won't 100% find out -- at this moment -- whether a library package is needed because the library can be dlopen()ed and this is usually not encoded into package requirements (yet), cf. the current "suggests/requires in rpm" thread. Nils -- Nils Philippsen / Red Hat / nphilipp(a)redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

On Mon, Jan 24, 2005 at 03:05:29PM -0200, Alexandre Oliva wrote: ATrpms has started marking library only packages with Provides: shared-library-package so these packages can be identifies with rpm --whatprovides shared-library-package and be probed for garbage collection. I.e. there is no need to extend rpm, you have everything already in place. -- Axel.Thimm at ATrpms.net

On Mon, Jan 24, 2005 at 02:32:43PM -0500, Jeff Johnson wrote: wow, nice trick, I'm impressed! With rpm one cannot stop learning :) Indeed, if all shared libs were already packaged in the suggested scheme, this would catch them all. I don't think everything should be packaged that way (distribution invariants like glibc for instance not), and such a idiom would also need its time to spread into rawhide, so having the Provides: shared-library-package is a good hook to distinguish leaf-disposable packages from others that are bundling libs and further stuff. -- Axel.Thimm at ATrpms.net

Harald Hoyer wrote: which is a data problem, maintaining magic with the latest and greatest rules, so that the appropriate rules are used and included in metadata when packages are built. Try file your-favorite-PIE-executable rpm gets the same answer as file, for exactly the same reasons. Patches cheerfully accepted! 73 de Jeff

Alexandre Oliva wrote: The concept of "pinning" can will stop a depsolver from unattended, batch mode, upgrades. But up2date certainly has (at least) the two essential "pinning" concepts: a) Never change this package. b) Never change this file. and yum has (at least) a). The real problem with "pinning" is one of mechanism vs. policy. The pain that you -- an active nerd ;-) -- might be willing to accomodate and tolerate is very different from what most users are willing to tolerate. An QA on upgrades in the face of "pinning" is way way more complex. Erasing unused packages has never been seriously attempted, mostly because the primary goal of installers and depsolvers is Upgrade! not otherwise. 73 de Jeff

Right but the problem is this. sometimes, when I know a dep a package needs i'll request it too. so instead of: yum install rdiff-backup I'll run: yum install rdiff-backup librsync So, I've requested it - but only b/c I know it's a dep. -sv

On Tue, 2005-01-25 at 14:44 +0100, Aurelien Bompard wrote: No, not necessarily. My point is that marking it based on what you _think_ the user is doing is not going to produce reliable results. -sv

It's not a question of why? It's simply that I did. -sv

On Tue, 2005-01-25 at 02:24 -0200, Alexandre Oliva wrote: The pacman package manager from Arch Linux (which I used to package GNOME for) seems to have recently gained a feature like this. It's fortunately better then just pinning; pinning means the package can't be upgraded. Basically, pacman marks for each installed package whether the package was pulled in explicitly by the user or as a dependency of another package. There is then a command that can remove any package which was not explicitly requested by the user and which is not depended on. If this was combined and made a little smarter to deal with RPM groups (something else that pacman supports, albeit in a much different way) then the method could be used in rpm and would probably work very well. Debian also has the deborphan utility, although it isn't very intelligent at all; it just bases its decisions on whether a package has dependencies, which can lead to a lot of manual intervention after it generates a package removal list. I think the model used by pacman is superior here.

Le lundi 24 janvier 2005 à 12:59 +0100, Aurelien Bompard a écrit : OK, look at Mandrake : libglib1.2-1.2.10-14mdk.i586.rpm libglib2.0_0-2.4.6-1mdk.i586.rpm Fedora : glib-1.2.10-15.i386.rpm glib2-2.4.7-1.i386.rpm C'est blanc bonnet et bonnet blanc :-)

On Mon, 24 Jan 2005 13:24:42 +0100, Aurelien Bompard wrote: Do what's necessary. If you no longer need the older libkexif, because you would rebuild its dependencies against the newer libkexif, you could simply upgrade and need not worry about moving the old one into a package like likexif0. Also note that multiple -devel packages often conflict (e.g. gpgme03-devel, gpgme-devel in pre-extras). Unless you moved libraries _and headers into separate versioned sub-directories.

Le lundi 24 janvier 2005 à 13:24 +0100, Aurelien Bompard a écrit : Why not. But : http://fedora.redhat.com/about/objectives.html Non-Objectives of Fedora Core: (...) 3-Being a dumping ground for unmaintained or poorly designed software. The objectives of fedora is not to provide support for legacy libraries. I use RH/Fedora for many years and personally, I don't really care about multi lib.so. I don't remember to be annoyed by this.

Aurelien Bompard wrote: Depsolvers (at least correctly written ones) use Provides:, not Name:, for choosing what packages to install. The only reason for ornamenting the package name with gunk is to attempt to provide a clue of differences through primitive HTTP/FTP browser GUI's. Usually a soname is slam-dunked, the library and every package that uses the library are changed at the same time. That works for the distro itself. 73 de Jeff

Michael Schwendt wrote: From multiply installed rpm -i? Sure, no application gets that right. I question "need" however, as "Don't do that." is workable alternative many years now, and there are other techiques, like readline43 and compat-db, that are sufficient for the MUSTHAVE problems. And after incompatible sonames, comes issues with --relocate that noone has ever attempted to solve the upgrade cases for. <shrug> But I'm sure the java heads will break *.rpm packaging with --relocate for their *.jar files if/when they discover --relocate. Again <shrug>, there's invariably something along the lines of "Don't do that." that can be devised. Because while it works for the distro, slam dunking does not work for 3rd party packing. In fact, slam-dunking is not gonna work for 2nd party packaging like Fedora Extras. What will happen instead (imho) is that library sonames simply won't change, even if they should. So put sonames into package names if that floats your fedora.us boat. Sooner or later you will run into kernel file system imposed limits on package file names. <shrug> 73 de Jeff

Nicolas Mailhot wrote: So I hear. What's sad is that "hardcoded classpaths" is exactly what rpm (and packaging) might help rationalize, mapping the classpath mechanism into package dependencies. rpm will get to java dependencies some day. I'm not gonna hold my breath, though, because java culture is so vastly different than other coding, and the java heads seem to wish to exist separate-but-equal until they get around to writing a kernel in java that runs everywhere. 73 de Jeff

Jeff Johnson wrote: How many characters could it add ? 2 digits ? 3 digits max ? How about that : $ rpm -q bash-completion bash-completion-0.0-0.fdr.4.20041017 I see your point, adding something else than the name into the package Name tag is opening the door to crazy things, like configure tags (is there really a Debian package with configure tags in the name ???). Still, I think that it could be very beneficial to provide easy upgrade paths. I think that the advantages overcome the shorcomings in this situation. Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info "Science sans conscience n'est que ruine de l'âme." -- Rabelais

Mike Hearn wrote: Well, libkexif is a few months old. We can expect unstability for new projects, and as one of Fedora's aim is to be on the bleeding edge, we will see this problem more and more frequently. Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info Recursion: (n.) See "Recursion".

Mike Hearn wrote: I'm not really talking about my particular package here, I can deal with 4 rebuilds at the same time (actually I've already done so). I'm trying to extract some kind of packaging policy for other libraries, on which many more packages could depend. Soname changes happen, sometimes, even with stable libraries. See for example the libpng mess that occured a few years ago. Statically linking should be an exception, and I'm trying to propose a general solution. Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info "Never trust a computer you can't throw out a window." -- Steve Wozniak

Charles R. Anderson wrote: True, but we would need something which can be set in the package itself. It looks like something unofficial is already used by Red Hat : if other packages depend on the old library, provide it in a different package containing the library's soname. For example, libpng and libpng10. Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." -- Linus Torvalds

On Mon, 2005-01-24 at 16:01 +0100, Michael Schwendt wrote: Using the rpm install method also breaks upgrades. Say you have libfoo-1.0 and libfoo-2.0. Many apps use libfoo-1.0 and will continue to do so because it's a massive API upgrade to libfoo-2.0. think gtk1 vs gtk2. Now a security bug is found in the 1.0 branch, and the developers realize that a lot of users are stuck with apps using that branch, so they release 1.1 with the security update (as the version indicates, it's backwards compatible with 1.0), so libfoo-1.1 is released. With rpm install-only packages libfoo-1.1 would not be installed unless the user manually told the system to do it, since libfoo-2.0 is installed and is newer. The only way for this to work is make RPM recognize that libfoo-1.0 and libfoo-2.0 are completely different packages. Just because they're both libfoo is irrelevant, they are different APIs and different ABIs. In GTK's case the second version just got a two appended. Packages are gtk and gtk2. While that works, in the general case, using the soversion probably just makes more sense. The packages could be, for example, libfoo1.0 and libfoo2.0. The specifics aren't that important, just so long as it works.

Le mercredi 26 janvier 2005 à 11:04 -0800, cfk a écrit : If you can setup an nfs or ftp/http server somewhere the fastest method is network install via kickstart (using pxe if you can) It might take a little longer to setup but you'll make up the time very fast. And if you do not have exactly the same hardware (same components & firmware versions) it's way safer. Regards, -- Nicolas Mailhot

On Wed, 26 Jan 2005 23:40:15 +0100, Kyrre Ness Sjobak <kyrre(a)solution-forge.net&gt; wrote: Don't use dd for this. If you have different size hard drive, partition or something else down the line, it can really mess you up. I would recommend a simple tar or rsync command to copy them over. This is if you wish to do copy machine to machine. Otherwise a custom kickstart file with pxe is a lot easier if done right. -- Christopher Hotchkiss (813)960-9273 http://www.post227.org

I wrote this about 2 years ago. I think it is still relevant. One of the ways I would improve it is to use a USB-IDE enclosure for the target drive as you wouldn't have to use Linux rescue nor reboot. FWIW : I just spent about 2 days figuring out how to easily clone a Linux HD. I'm writing this to hopefully save someone else the grief that I've gone through. I'm a relative newbie to Linux. I'm sure the experienced Linux people can enhance/correct/improve what I've written here, but at least this works. My setup is a PC clone with multiple HD bays and a CDROM player. My source drive is a 6.4 GB IDE hard drive with 3 partitions: boot, swap and root. It is nearly full. I'm running RH8.0 using kernel 2.4.18.something. The new drive, herein called the "clone", is a 60 GB IDE hard drive. The major steps to cloning a HD are as follows: 1) partition the clone drive 2) format each partition on the clone drive 3) copy files from the old drive to the clone drive 4) set up grub on the clone drive 5) boot it. The whole process sounds intimidating, but it really isn't any different or harder than cloning a DOS drive. Some people say that one should just install a fresh copy of Linux on the new drive, making it a new install rather than a clone install, but that is MUCH more work than just making a clone. My old drive has numerous patches, updates, installs and data installed just about everywhere. It works exactly as I want it to. I wouldn't want to repeat the work that it took to achieve that, so I'll clone it rather than start afresh with a new drive. We use removable hard drives on our PCs. For absolute data safety, when partitioning and formatting hard drives, I remove all drives except the one that I am working on and run from a boot disk. One could easily perform all this work with the new drive mounted alongside an existing drive, but I don't. Thus, all my commands are based on the clone drive being installed as /hda and running from linux rescue. If you are performing your clone with the clone drive installed alongside an existing drive, your commands will be based on /dev/hdb or /dev/hdc, for example. I also assume that the reader knows how to set up his/her BIOS so that it has the proper boot order when needed, ie boot from CDROM first so that linux rescue can be run. In detail: 1) Partition the clone drive. I partitioned the clone drive by running fdisk from linux rescue booted from the install CDROM. When running linux rescue, I DO NOT let the OS mount the hard drive. I always do that manually from the command line when I am doing system maintenance. Once at the command prompt in linux rescue: #/sbin/fdisk /dev/hda Obviously you will change this to suit your partitions and partition types. REMEMBER THAT I INSTALL THE CLONE DRIVE AS PRIMARY MASTER IE: /dev/hda. IF YOU DON'T DO THIS, YOU NEED TO CHANGE THE DRIVE SPECIFICATION This will start fdisk. From here you are on your own. I created 3 linux partitions: boot, swap and root. I made boot (/dev/hda1) to be 100 MB in size and used ext3 for the file system. I made the swap partition (/dev/hda2) twice as big as my motherboard RAM, or 512MB x 2 = 1 GB. It used the Linux swap file type. I made the root (/dev/hda2) partition consume the rest of the drive and gave it a ext3 file type as well. NOTE: One should set the label of the partitions while using fdisk. I didn't and had to later. The root drive (/dev/hda3), for example, should be given a label of "/" to properly work with grub as we'll see later on. 2) Format the partitions If you are following my drive layout, these are the commands you will use. a) Format the boot partition as ext3: #/sbin/mkfs.ext3 /dev/hda1 b) Format the swap partition as linux swap: #/sbin/mkfs.swap /dev/hda2 c) Format the root partition as ext3: #/sbin/mkfs.ext3 /dev/hda3 Obviously you will change this to suit your partitions and partition types. REMEMBER THAT I INSTALL THE CLONE DRIVE AS PRIMARY MASTER IE: /dev/hda. IF YOU DON'T DO THIS, YOU NEED TO CHANGE THE DRIVE SPECIFICATION 3) Copy the data from the old drive to the clone drive. To do this, I reboot my computer with both the source and the clone drive in the bays. I usually boot with the source drive in /hda (ie primary master) and the clone drive in /hdc (ie secondary master). My reasoning for doing this is that sometimes new drives (ie the clone) have much newer technology than the old drive and the two will not operate properly on the same ide channel. By putting one on the primary channel and the other on the secondary channel, I can clone really old drives (1995 vintage 1 GB, for example) onto new drives (latest 120 GB) without any problems. There are two partions that we need to copy data from: the boot partion and the root partion. I prefer to do these copies as two distinct mounts and copies. One could mount the source drive hierarchically and also the clone drive and then issue one copy command, but for only 2 partitions I prefer to do 2 separate copy commands. Again I boot linux rescue from the CDROM and bypass any automatic mounting of filesystems. First I mount the old boot partion as /oldboot # cd / # mkdir oldboot # mount -text3 /dev/hda1 /oldboot # cd oldboot # ls <you should get a listing of your old boot partition here> Next, I mount the new boot partition as /newboot #cd / # mkdir newboot # mount -text3 /dev/hdc1 /newboot # cd newboot # ls <you should get a listing of nothing here because it should be empty> Now, I copy the data from the old boot partition to the new boot partition: # cp -aR /oldboot/* /newboot 2>/newboot/error.log The -a attribute tells cp to keep all of the current attributes. The -R attribute tells cp to do a recursive copy. optional: if you want to watch the filenames stream by while they are being copied, add a "-v" to the attributes, ie "-avR" The "2>error.log" tells the OS to redirect the stderror output of cp into the error.log file in /newboot. The boot partition is fairly small, so this shouldn't take very long. When the copy is done, I do the following: # cd /newboot # ls <a display of the new partition should occur. It shouldn't be empty> # more error.log < a display of the error.log file should appear. It should be empty or nearly so .> Note: one could write a script that compared the attributes of every file in /newboot to every file in /oldboot, but I haven't found this to be necessary. As long as there are no alarming errors in error.log, the new partition should have all the files that the source drive had. Now I repeat that copy process for the root partition: # cd / # mkdir newroot # mount -text3 /dev/hdc3 /newroot # ls /newroot <should be empty> # mkdir oldroot # mount -text3 /dev/hda3 /oldroot # ls /oldroot # <should contain root stuff> # cp -aR /oldroot/* /newroot 2>/newroot/error.log # cd newroot # ls <a dislpay of the new root should be here> # more error.log If both error.log files are clean, consider your copy successful. Although the partitions and formated and the data has been copied, the clone drive is still not bootable. BTW: many experienced linux people will tell you to use dd or tar or several other copy processes together with pipes and redirection. They might be faster, but I had trouble with most of them in one or more situations. cp is easy to understand and I've yet to find an instance where it doesn't work. 4) Set up grub on the new drive. Here is where I got hung up and where most people get stuck. First, we need to install grub into the boot sector of the boot drive/partition. This does NOT occur automatically when formating the boot partion, nor when copying the root files. This is akin to performing a >sys c: in Dos. To install grub on the boot sector, we need to run something called grub-install from the command line, but first we must mount our filesystem and set up a new root directory using our new filesystem. Here is how I do that: a) boot linux rescue with the clone drive installed as /hda ie primary master. (It could actually be done with the drive mounted anywhere.) b) mount the new cloned filesystem as it will be in the computer when running, but mount it under /new. NOTE: some people will tell you to mount it under /mnt, which already exists in linux rescue. Don't do this. Why ? Because the command shell for linux rescue appears to be running under /mnt and when/if you mount the new filesystem under /mnt, you will no longer have a shell to run under ! Ie, you won't have access to ls, mount, chroot, etc. So, here are my commands: # mkdir new # mount -text3 /dev/hda3 /new # ls /new <listing should occur here> # mount -text3 /dev/hda1 /new/boot # ls /new/boot <listing of /boot should occur here> We've now got our cloned filesystem mounted exactly as it will be in our new system, but under /new. The boot partition (/dev/hda1) is mounted in /boot just like it will be when we run the drive. We didn't really need to do the root hierarchical mounting, but I like it that way. Now, we change the root directory of our filesystem and start a new bash shell. We need to do this because grub-install is not present on the linux rescue shell: # chroot /new /bin/bash This command will make / be what /new/ was. It will also start /bin/bash, which was /new/bin/bash, which is the bash shell on our cloned drive. We can now go to work using all the tools present on our cloned drive, ie all the tools that were present on the old drive. We can actually startX is we need to, although I never have. We need to install grub onto the boot sector of the boot drive, so: # /sbin/grub-install /dve/hda1 BTW: if we want to learn about grub, we can use man grub or info grub now. info grup-install is interesting to read. Neither man nor info are available in linux rescue mode. Grub is now installed on the boot sector, but sometimes it needs to be configured to find grub.conf. Grub.conf is the configuration file that grub runs to know what kernels to offer for booting, where the images are, etc. Grub config is located in hda1/grub/, which is really /boot/grub. (Remember that we mounted hda1 as /new/boot/, but our chroot changed that to /boot/.) "info grub" in the FAQ part contains this nice little gem: <paste begins> I have a separate boot partition and GRUB doesn't recognize it. This is often reported as a "bug", but this is not a bug really. This is a feature. Because GRUB is a boot loader and it normally runs under no operating system, it doesn't know where a partition is mounted under your operating systems. So, if you have the partition `/boot' and you install GRUB images into the directory `/boot/grub', GRUB recognizes that the images lies under the directory `/grub' but not `/boot/grub'. That's fine, since there is no guarantee that all of your operating systems mount the same partition as `/boot'. There are several solutions for this situation. 1. Install GRUB into the directory `/boot/boot/grub' instead of `/boot/grub'. This may sound ugly but should work fine. 2. Create a symbolic link before installing GRUB, like `cd /boot && ln -s . boot'. This works only if the filesystem of the boot partition supports symbolic links and GRUB supports the feature as well. 3. Install GRUB with the command `install', to specify the paths of GRUB images explicitly. Here is an example: grub> root (hd0,1) grub> install /grub/stage1 d (hd0) /grub/stage2 p /grub/grub.conf <paste ends> I like option number 3, so that is what I run. However, my boot drive is /dev/hda1, which is (hd0,0). (See info grub for info on how grub specifies drives. Remember that all drive numbers in grub are base 0, not base 1). I thus run the following commands: # grub grub> root (hd0,0) grub> install /grub/stage1 d (hd0) /grub/stage2 p /grub/grub.conf <if you've got the directories and drive number right, there won't be an error. If one is wrong, there will be a file not found error> grub> exit Grub itself is now set up in the boot sector and it knows where grub.conf is. If grub.conf worked well in the source drive, it should work well on the cloned drive. At this point, your drive is bootable, although it probably won't boot. Here is the rub: many of the entries in grub, automount and init files refer to drives by their LABEL. Yes, there are now 3 ways to refer to drives in Linux: 1) by the device ie: /dev/hda1, hda2, etc. see man mount for more on this. 2) by the grub specification ie: (hd0,0) see info grub for more on this. 3) by the drive label. It is handy for certain linux processes to be able to refer to drives by their function (ie root, boot, etc.) rather than have them hardcoded into the /dev/ spec. Thus, certain processes refer to drives by their label, which is chosen to indicate their function. It turns out that certain processes in the boot process refer to the root drive by its label, which they expect to be "/". In order for our clone drive to boot properly, we need to set its label to "/". Issue the following command to do this: # e2label /dev/hda3 "/" There might be other ways to do this, like during fdisk or mkfs, but I am a newbie, remember. I think that labels can be checked with hdparm, but I can't remember. Interestingly enough the clone drive boots with only the label for root changed. I did not have to change the label for the boot partition. However, I'm sure that somewhere there is an application or process that will refer to the boot partition by its label, thus I would set its label to /boot as well: # el2label /dev/hda1 "/boot" Your clone drive should now be an exact image of the source drive and bootable. Using Clones I keep a small, outdated drive with nothing but a clean, uptodate copy of Linux on it. Anytime we need to build a new drive for a new computer or a new process (in an existing computer via installing a new drive), I just clone the "clean" drive. This works really well with new users (friends) because I know how everything is set up and they don't have to muddle through the installation process. The Beauty of Linux This whole process could actually be done as one script, with the grub commands put into a separate grup scrip file. I haven't done it yet, but the whole cloning process would just be a script that could be run at some period of convenience, like just before leaving work for home or just before going to bed. I removed the source drive while formatting and partitioning and rebooted /remounted when setting up grub, but that wouldn't have to be done that way. One more thing: the cloning script could run the new drive and add a few default users as well as initiate the email client. Enjoy !!! possible changes: use mirrordir, but it isn't available on most machines without installing an RPM Change the cp attributes. cp /dir/* won't copy the dot files in /dir/ and this: <paste> You are a bit wrong with the cp arguments: the -a arguments archives a whole directory structure, which means: - preserves uig/gid/timestamps, - archives recursively - Doesn't go through symbolic links (it just copies them as well) So, to mirror your harddisk, just: cp -avx / /mnt/newdisk -v: To view what is being done. -x: To stay to the current filesystem. <end of paste> Lastly, mkdir /proc -- Kim Lux, Diesel Research Inc.

On Monday 24 January 2005 23:11, seth vidal wrote: Munge the release tag! ;) -- -jeff

Jeff Johnson wrote : Nice one, "bulldozer style". Never thought of it before :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.10 0.30 0.51

On Fri, Jan 28, 2005 at 07:57:09PM +0100, Matthias Saou wrote: It does tend to make a nasty mess of update tools however. If you want to do this for the normal situation just bump the epoch of your private rebuilds

Ralf Ertzinger wrote: rpm -e N-V-R && rpm -i N-V-R.A.rpm is exactly an update. 73 de Jeff

On Mon, 24 Jan 2005, Aurelien Bompard wrote: In this particular case, my suggestion would be to bite the bullet and upgrade libkexif and all apps that depend on it. While were on the subjet of exif, any reason fedora-devel hasn't upgraded to libexif-0.6.x yet? libkexif-0.2.1's configure scriptlet strongly recommends it. -- Rex

On Mon, 24 Jan 2005, Aurelien Bompard wrote: If it *must* be done, you need to follow (appoximately at least) Mandrake's style, and build libkexif0 libkexif1 ... etc With each (ideally) including Provides: libkexif = %{version} Also, doing it this way, You can't ever have a *real* libkexif rpm pkg anymore due to a recent rpm bug... err... feature: http://bugzilla.redhat.com/bugzilla/130352 http://bugzilla.redhat.com/bugzilla/111071 -- Rex

On Mon, Jan 24, 2005 at 11:34:03AM +0100, Aurelien Bompard wrote: Yes, please. This is very important for smooth upgrades, i.e. no pressure to rebuild all dependent packages in one atomic step. This becomes even more important for a community with multiple repos like fedora core is evolving to. I think this is an area, where other distributions have found nice solutions and Fedora/Red Hat should simply use one of the existing policies (instead of creating one from scratch). I think there aren't that big differences in Mandrake's vs Debian's policies. BTW ATrpms has been converting library packages to use this scheme for quite some time in order to have good gluing components between the various repos. -- Axel.Thimm at ATrpms.net

On Mon, Jan 24, 2005 at 10:22:13PM +0200, Ville Skyttä wrote: But on the contrary it is not directed compatibility, but rather a unilateral, you have a scheme for both forward and backward compatibility packages, so that third parties (as well as Red Hat as a vendor itslef) can easily move forward to the next bleeding edge softwrae release. In the sense of the above I would even see them as promoting arguments. Currently if Red Hat ships libfoo.so.2 and you want to have libfoo.so.3, so need to go through a couple of hops, replace core packages with compatibility libs (or even worse, not care about dependencies on libfoo.so.2) and finally called a heretic. Been there, seen that ... If this idiom already existed, one would simply package the new library into libfoo3 and no clashes/replacements with libfoo2 would occur. (But note: the above is slightly simplified, there are a coupdl of controlable issues that must be taken care of). If we are talking on naming schemes we cannot only consider Fedora, as its bigger brother RHEL will share the same. But I believe that the soname-in-rpmname based approach is both suitable for a stable ABI like RHEL as well as a fast pacing one like Fedora's. At the very end it only adds flexibility at the cost of required garbage collection that can easily be solved. And note that the frame objectives of the two distributions already deploying this scheme are indeed very close to RHEL (infinite release cycles of Debian ;) and Fedora (Mandrake's latest and greatest). -- Axel.Thimm at ATrpms.net

On Tue, Jan 25, 2005 at 12:34:27AM +0200, Ville Skyttä wrote: There's no need to, these packages can be easily marked (see my other replies in this thread) and removed even in cron-jobs. I don't want any backward compatibility _content_ in Fedora, but a proper forward/backward combatibility _mechanism_. Fedora Core (rawhide) should continue its aggressive schedule, it only allows for flexibility when needed. It even allows to skip concerning about creating compatibility libs for selected bits of Fedora Core N-1 and N-2 for Fedora Core N, since the libs from the previous releases can effectively simply be copied over with no renames to compat-this and compat-that, and most importantly no new QA, you know they worked for any ISV. So I guess we are on the same side ;) -- Axel.Thimm at ATrpms.net

On Tue, Jan 25, 2005 at 01:19:46AM +0200, Ville Skyttä wrote: There isn't anything wrong in having these packages follow the soname-in-rpmname idiom. Even if there would be no further need for concurrent libs it would solve the leftover libs of previous Fedora Core/Red Hat Linux installations. I only see added value at no real cost: the required simple garbage collector pays off immediately for not having to obsolete old forward compatibility packages (like the gcc34 example, not a library, but the same packaging issues apply here). -- Axel.Thimm at ATrpms.net

On Tue, Jan 25, 2005 at 06:11:25PM +0800, Jeff Pitman wrote: I agree that this bug needs to be fixed somehow, but in the case of soname-in-rpmtag you don't run into the problem, as the libfooN packages don't share any common provides, neither real nor virtual. Otherwise I would have noticed, multiple libfooN packages have been in ATrpms since ages now, not to think of Mandrake. :) -- Axel.Thimm at ATrpms.net

On Tuesday 25 January 2005 19:19, Michael Schwendt wrote: Uh, yeah. 130352 was submitted after discussion between Rex, Axel, and I when 111071 couldn't be found. 111071 was eventually found but we realized it to be a dead-end discussion. 130352 has the trimmings of an RFE, rather than a bug report. Maybe the report should be modified and reworked as such so we can make progress on this. -- -jeff