Benjamin Reed wrote: > Once we have automated builds of any kind, we can start promoting > packages from unstable -> stable automatically or semi-automatically, > because we'll really know how info files and the state of binaries map, > and we can solicit and receive feedback on packages from end-users more > easily. > > I intend to work on this as soon as I can, although right now is a bad > time for me because of huge amounts of work commitments. I hope to make > the time anyways. :)
That's great to hear. One thing I'm wondering if would be possible to do as part of this semi-automation is a dependency engine that better knows what packages are available and is used to parse the output of 'fink list'. I wondered about this as drm did his 10.6/x86_64 trimming. Currently, one of the more common errors that is reported is a missing dep because a package has a (versioned) dependency that is no longer in the database. So if I maintain $user-package which requires $libs, I need to keep aware of its happenings, especially if I ever want to move it to stable. For example, SDL originally failed to build on 10.6 and was marked as "10.4, 10.5". This meant that any package that depended on SDL (which are many), then also had to be marked as "10.4, 10.5", otherwise, errors about missing dependencies would occur to people trying to install $sdl-dependent. And when SDL was fixed, all those packages also had to be marked as available. This takes a lot of manual effort, and could lead to errors because $sdl-dependent might have been marked as !10.6 for other reasons, and an automated scanner/fixer would not know that. But if 'fink list/install' knew about dependencies, it would not show non-restricted $sdl-dependent as available unless all of its dependencies down the tree were available. So if SDL is restricted, SDL-net (and even deeper dependents) would not need to be marked as restricted. 'fink list wormux' (eg) would check the tree, see that wormux needs SDL-net, see that SDL-net depends on SDL and since SDL is restricted, it would not even list wormux (or SDL-net) in the list of available packages. The big benefit of this system is that once SDL becomes unrestricted (or just available), SDL-net and wormux (assuming they work of course), would immediately become available to the end user without $maintainer having to do anything. This would also help $maintainer deal with arch/dist combos to which s/he has no access for testing. And finally $user would not get errors about missing dependencies. I think the biggest impediment to this becoming reality is that the _entire_ dependency tree will then need to be stored somewhere after its creation by 'fink index', rather than a limited and specific subtree rooted on $user-package created and destroyed from scratch at every 'fink install'. Hanspeter ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
