Re: [Fink-devel] essential splitoffs
On Friday, Jun 13, 2003, at 12:56 US/Eastern, David R. Morrison wrote: And in fact, we've had a policy (unstated, I believe) that there was no need to specify any dependencies on an essential package. Debian's policy on the matter is that versioned dependencies on essential packages must be declared; unversioned ones do not need to be. --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
Anthony DeRobertis <[EMAIL PROTECTED]> wrote: > On Thursday, Jun 12, 2003, at 16:12 US/Eastern, David R. Morrison wrote: > > > > At that point, it might be possible to switch which package is > > essential > > from gettext to gettext2. However, if other packages have *assumed* > > that every essential package is present and doesn't need to be > > declared, > > then it won't be possible to make this switch. > > My point is there should already be a versioned dependency on gettext > (because of libintl) created by dpkg-shlibdeps (or the Fink equiv.) > Ah, now I see your point. This is true, there should be, but we have not yet finished implementing the equivalent to dpkg-shlibdeps. And in fact, we've had a policy (unstated, I believe) that there was no need to specify any dependencies on an essential package. It is that policy which I'm trying to change. -- Dave --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
On Thursday, Jun 12, 2003, at 16:12 US/Eastern, David R. Morrison wrote: At that point, it might be possible to switch which package is essential from gettext to gettext2. However, if other packages have *assumed* that every essential package is present and doesn't need to be declared, then it won't be possible to make this switch. My point is there should already be a versioned dependency on gettext (because of libintl) created by dpkg-shlibdeps (or the Fink equiv.) For example, apt-cache showpkg libc6 (an essential package, of course) shows: $ apt-cache showpkg libc6 Package: libc6 Versions: 2.2.5-11.5(/var/lib/apt/lists/ security.debian.org_dists_stable_updates_main_binary-i386_Packages)(/ var/lib/dpkg/status) 2.2.5-11.2(/var/lib/apt/lists/ http.us.debian.org_debian_dists_stable_main_binary-i386_Packages) Reverse Depends: nessus,libc6 2.2.4-4 smake,libc6 2.2.4-4 libber0,libc6 2.2.4-4 libnasl1,libc6 2.2.4-4 bidwatcher,libc6 2.2.4-4 smartmontools,libc6 2.2.4-4 cdrdao,libc6 2.2.4-4 libconfig0,libc6 2.2.4-4 libgd-tools,libc6 2.2.4-4 nessus-plugins,libc6 2.2.4-4 amap,libc6 2.2.4-4 libgd2-xpm,libc6 2.2.4-4 gtk-gnutella,libc6 2.2.4-4 nessusd,libc6 2.2.4-4 tuxtime,libc6 2.2.4-4 ... (there are 5427 lines total) --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
When a library gets a non-backward-compatible upgrade, fink's shared libraries policy (which was borrowed from Debian), insists that the package which contains the shared library should get a new name. The library itself will get a new name too: for example, the gettext package currently installs /sw/lib/libintl.1.dylib as the primary library, whereas a new gettext2 package will install /sw/lib/libintl.2.dylib as the primary library. We mark things "essential" when fink itself requires them to be present in order to function. Since fink calls dpkg, the things which it depends on will also be needed. At present, dpkg links to /sw/lib/libintl.1.dylib . At some point in the future, though, dpkg might link to /sw/lib/libintl.2.dylib. At that point, it might be possible to switch which package is essential from gettext to gettext2. However, if other packages have *assumed* that every essential package is present and doesn't need to be declared, then it won't be possible to make this switch. Hope this helps to clarify. -- Dave --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
On Saturday, Jun 7, 2003, at 11:16 US/Eastern, David R. Morrison wrote: 1) Proposed New Policy: You must declare any needed Depends or BuildDepends of your package on essential packages. If you do this for even unversioned dependencies, what's the point of having essential packages anymore? --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
On Monday, Jun 9, 2003, at 13:11 US/Eastern, David R. Morrison wrote: If other packages have not been required to specify their dependency on gettext-shlibs, things will break at that stage. Ummm, if packages depend on a specific version of gettext (like a library dependency does), shouldn't there already be a dependency there? It shouldn't matter if gettext is essential or not. Of course, apt-cache showpkg gettext shows troubling results. What happens if: 1) User installs essential library liba-shlibs-1.0 2) New liba-shlibs-1.1 is released. Is backwards compatible, so the soname need not be changed. However, it adds a new feature 3) Package foo-0.9 is released, linked against liba-shlibs-1.1 4) user does "apt-get install foo" Either foo has a depends on liba-shlibs >= 1.1 or problems result. Whether liba-shlibs is Essential: yes is irrelevant. (Try an apt-cache showpkg libc6 on a Debian system sometime; a LOT of reverse dependencies will show up, despite libc6 being Essential: yes. At least in Debian policy, if a package needs a specific version of an essential package, it must declare a dependency.) --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
On Monday, June 9, 2003, at 05:54 PM, jfm wrote: On Tuesday, Jun 10, 2003, at 00:27 Europe/Brussels, Max Horn wrote: Still don't see the point: if at some point we have a gettext2-shlibs, then it will at some point become essential, too. Period. The "old" gettext-shlibs wouldn't stop being essentia - after all, why should it? The only reason would be "shorter bootstrap time" - but I don't think it would actually work, unless the new gettext is 100% source compatible, we'd still need the old gettext anyway. I would have thought that the "old" gettext-shlibs would naturally stop being essential as soon as there is a version of dpkg depending on a newer one. Where is my misunderstanding ?? Packages will still be linked against the old gettext-shlibs, and if its not essential or depended on, it will be removable, which will break things. The new header -dev pacakges (gettext-dev & gettext2-dev) cannot be "Essential" because they have to be swapped out at will by packages. If they aren't "Essential", then they won't always be there. If they aren't always there, then they MUST be BuildDepended on, so they get installed when needed. A->B->C :) Thus: I agree with drm here, unless we are going to have the same set of essential packages at the same versions (the current ones :) forever, we need to add depends on them to everything. It isn't that hard, it can all be scripted as i said. -Ben --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
On Tuesday, Jun 10, 2003, at 00:27 Europe/Brussels, Max Horn wrote: Still don't see the point: if at some point we have a gettext2-shlibs, then it will at some point become essential, too. Period. The "old" gettext-shlibs wouldn't stop being essentia - after all, why should it? The only reason would be "shorter bootstrap time" - but I don't think it would actually work, unless the new gettext is 100% source compatible, we'd still need the old gettext anyway. I would have thought that the "old" gettext-shlibs would naturally stop being essential as soon as there is a version of dpkg depending on a newer one. Where is my misunderstanding ?? Jean-Francois --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
Am Montag, 09.06.03 um 19:11 Uhr schrieb David R. Morrison: Here's the point: there is a new version of gettext with a new major version number for the library. In an ideal world, we would have gettext-shlibs, gettext-dev, gettext2-shlibs, and gettext2-dev all available. (This is what I am trying to achieve, in fact.) Now, which of these are essential? Well, clearly we don't want the -dev packages to be essential. We *do* want the gettext-shlibs to be essential for now, since dpkg depends on it. However, at some future date we will probably want to compile dpkg with gettext2-shlibs instead of gettext-shlibs, and so we'll want to change which one is essential. If other packages have not been required to specify their dependency on gettext-shlibs, things will break at that stage. Still don't see the point: if at some point we have a gettext2-shlibs, then it will at some point become essential, too. Period. The "old" gettext-shlibs wouldn't stop being essentia - after all, why should it? The only reason would be "shorter bootstrap time" - but I don't think it would actually work, unless the new gettext is 100% source compatible, we'd still need the old gettext anyway. Max --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
Here's the point: there is a new version of gettext with a new major version number for the library. In an ideal world, we would have gettext-shlibs, gettext-dev, gettext2-shlibs, and gettext2-dev all available. (This is what I am trying to achieve, in fact.) Now, which of these are essential? Well, clearly we don't want the -dev packages to be essential. We *do* want the gettext-shlibs to be essential for now, since dpkg depends on it. However, at some future date we will probably want to compile dpkg with gettext2-shlibs instead of gettext-shlibs, and so we'll want to change which one is essential. If other packages have not been required to specify their dependency on gettext-shlibs, things will break at that stage. -- Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
Am Montag, 09.06.03 um 14:13 Uhr schrieb David R. Morrison: Hi Max. I agree that caution is necessary in executing this change. Didn't believe you'd think differently anyway :-) There are really two things being changed here: (1) we now insist that dependencies on essential packages should be stated, Err... we do? Doesn't make sense. Things which are essential are always installed. So why would we do that? Don't you mean: "Some things which used to be essential would not be essential anymore and hence packages now have to depend on them" ? I.e. you have to depend on gettext-dev, but still don't have to depend on gettext (=the shlibs part). Maybe I am missing something vital here, please enlighten me :-) and (2) in addition to that, we're going to change the setup of the essential packages. It's hard to figure out the correct order to do these in. We can't ask for a dependency on ncurses-shlibs right now, for example, since it doesn't exist. I already proposed creating a "fake" ncurses-dev for use during the transition, so maybe we could do the same thing for ncurses-shlibs? Create fake packages for these, insist that all dependencies on them be declared, and only then convert to the new system? See above, I don't quite follow you here - why would stuff have to depend on ncurses-shlibs, wouldn't it be essential? Or put the other way around, why would it not be essential? It should be, it seems. Max --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
Hi Max. I agree that caution is necessary in executing this change. There are really two things being changed here: (1) we now insist that dependencies on essential packages should be stated, and (2) in addition to that, we're going to change the setup of the essential packages. It's hard to figure out the correct order to do these in. We can't ask for a dependency on ncurses-shlibs right now, for example, since it doesn't exist. I already proposed creating a "fake" ncurses-dev for use during the transition, so maybe we could do the same thing for ncurses-shlibs? Create fake packages for these, insist that all dependencies on them be declared, and only then convert to the new system? My original proposal certainly has the drawback that it leaves a lot of cleanup for later. However, it also has the advantage that after executing a single step (addition of BuildDepends on -dev), we can actually *convert* to the new setup of essential packages. It's probably much easier to get the revision of dependencies to work out right if the things you are depending on actually exist at the time. -- Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
I am not too fond on rushing this out or putting it into unstable that soon. Simply for the reason that going back is hard, and if we determine that we made a mistake in that switch, that it was a bad move after all or should have been done slightly differently, we then have just painted ourselves into a corner, facing a hard time getting back out. I don't like the part where you add BuildDepends automatically to all packages in a statical manner. At the very least, before you do that on unstable it *must* be tested by some individuals for some time in a local setup. In particular I am afraid of Fink erroring out with duplicate node errors etc.. I'd much prefer, if we decide to go with this route, a semi-intelligent approach as Ben Hines suggested it, namely adding only BuildDepends which are really needed. I mean, look at the last round of automatically added BuildDepends: there are still plenty of packages for which those were never cleaned up. You proposed: BuildDepends: bzip2-dev, gettext-dev,gettext-bin, libiconv-dev, libconv-bin, ncurses-dev Well, the "bzip2-dev" seems to be completely unnecessary: I am not aware of any single package needing it; and if there are packages needing it, I'll be there are maybe 2 or 3 at the most, in all of Fink. So adding that seems pointless, much better to find and fix those few packages. And the other could indeed by covered by an semi-automated search system. I see the merits of the system, but I think we should execute any such switch with extreme care and rather not rush it in any way, precisely because it'll be so hard to correct any mistakes we make in this. Max --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
On Saturday, June 7, 2003, at 08:16 AM, David R. Morrison wrote: 1) Proposed New Policy: You must declare any needed Depends or BuildDepends of your package on essential packages. (This will allow us in the future to change which packages are essential, without destroying the entire Fink setup.) I was afraid of this when we were actively removing those a few months back. Anyway, I think we can partially script this as well. I think we already have a script that can run otool on fink binaries and tell you which packages it needs, that can be extended to just email the maintainers with a list of all their packages, and what libraries they 'appear' to depend on based on otool -L'ing every file in the package. (highlighting ones that are not currently listed) That could also be added to an advanced fink validate for .deb files, perhaps. Anyone want to have a hack at it? :) to get you started: % dlocate -L tar | xargs otool -L ... /sw/bin/tar: /sw/lib/libintl.1.dylib (compatibility version 2.0.0, current version 2.1.0) % dlocate -S /sw/lib/libintl.1.dylib gettext: /sw/lib/libintl.1.dylib (you can also use dpkg instead of dlocate, but dlocate is much faster) :) -Ben --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
And finally, let me explain the motivation for this change a bit more. We are unable to update essential packages which have shared libraries, if those libraries get a change in their major version number, without the splitoff mechanism. This has already happened for gettext, the latest versions of which have a new major version number for the shared library. We've got to be able to shuffle gettext-dev and gettext2-dev back and forth. As long as we're doing this for one of the essential packages with shared libraries, we might as well do it for all four, to take care of possible future needs. -- Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] essential splitoffs
More details about my proposed change to the essential packages. I've now made some packages, in my experimental tree, which can serve as placeholders for the new splitoffs of essential packages during the transition. Here's how it would work: First, I'll put these new packages (for things like gettext-dev and gettext-bin) into both the stable and unstable trees. These packages are "Type: bundle" which install no files and depend on nothing. Their version/revision numbers will match those of the currently installed essential packages. (Before you ask "why", keep reading.) Second, I'll add the line BuildDepends: bzip2-dev, gettext-dev,gettext-bin, libiconv-dev, libconv-bin, ncurses-dev to every existing fink package, in both stable and unstable trees. Now the necessity of those "transitional" packages becomes clear: they let me add the BuildDepends in both stable and unstable at the same time, without messing up anybody's builds. Third, I'll release fink-0.13.1 and also the new splitoffized versions of the essential packages to unstable. Hopefully, everything will go well, but perhaps I should put a "how to downgrade" note on the website as this is happening, just in case? (The downgrade will be complicated, involving --force-depends and so on...) Finally, after testing, we could move both fink-0.13.1 and the newly splitoffized essential packages to stab.e Comments? Questions? -- Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
