Fink:Roadmap:Medium Term Goals

From the Fink Wiki
Jump to navigation Jump to search

This page tracks features or bug fixes that could or should be implemented in a future fink release. This may includes major new feature. For smaller or high priority features or bug fixes please refer to the Near Term Goals page.

  • more indexing work
    • refactor into Indexer.pm and possibly other modules
    • load-on-demand
    • version the DB
    • forget_packages should have better options
  • dep-engine refactoring work?
  • External API (so scripts can 'use Fink') 'use Fink' works in CVS
  • optimizations
    • auto-split PkgVersion?
  • bug fixing!
  • dist-upgrade?
  • automatically detect users' location, even for binary install
  • launchd support. We may have to get this done before 10.5, since the old StartupItems mechanism is deprecated.
    • Modify daemonic so that it turns DaemonicFile/Name into launchd plists on 10.4 and above. (make sure 'daemonic install' checks for and removes an existing StartupItems if it installs a LaunchAgents)
    • Add a new field for explicitly specifying launchd plist files to be placed in /Library/LaunchAgents (or LaunchDaemons? what's the difference?). This should also automate calling launchctl load and unload in PostInst and PreRm. (What about backwards compatibility, what would happen on 10.3?)
      • LaunchDaemons start up on system boot. LaunchAgents start up for each user when that user logs in (at the console only, probably) —msachs
    • Lingon is a really nice editor for launchd plists. It is open-source and could provide some good code to get the changes to daemonic started.
  • make AutoScanpackages default to true (requires that an apt-ftparchive binary be available as part of the default installation).
  • Try to conditionalize more fields
    • AppBundles, DocFiles, JarFiles, Files, ConfFiles, InfoDocs
    • Source and Patch (maybe wait for new Source blocks)
    • SplitOff?
    • Set*--probably trivial to do (piggyback on the ConfigureParams parser)


  • Create command-line tools for things fink does in PostInst and other maintainer scripts. Eg: fink-update-pod, fink-app-bundles.
    • Currently, fink inserts bash code in the PostInst, so when you upgrade fink you still have old .debs around with old code.
    • If the PostInst just said 'fink-update-pod' (with any reasonable arguments) then the debs would automagically use the new code.
    • Packages that use scrollkeeper and gconf would benefit here, since it's a pain to put the various multiline bits (that could change with future scrollkeeper or gconf versions and makes validation checks for their presence easier. I think at a minimum the same args passed to PostInst plus some package details would be good as generic interface for this kind of thing...simplifies the migration and leaves us completely open for future enhancements.
    • Note that we'd have to automatically add a Depends: fink (>= X), where X is the earliest version of Fink that provides all the command-line scripts needed for this package's Postinst/Prerm.
  • A 'fink env' command. Use case is 'eval `fink env foo`', which sets up the environment in the current shell as if it would be used to build foo. This allows foo to be built manually.
    • dmacks: I see on #fink you also mentioned installing deps; good idea! Something like:fink install-dependencies [--build] foo or fink install-[build-]dependencies foo (just runtime, or optionally also build-time deps/cons for a given pkg).
  • consider copying dports trace-mode: conditional on a cmdline option, use DYLD_INSERT to monitor what files are opened during a build...then we can check for missing deps? Would be necessary to use FORCE_FLAT, which could be dangerous.
    • After discussion with pogma and msacshs, it appears that FORCE_FLAT now can cause the wrong symbol to be used (rather than crashes, as under 10.2). In this case, we have to be much more careful to ensure that this doesn't cause data corruption.
  • Begin splitting PkgVersion up into reasonable size chunks. Splitting shall be on functional borders, ie: where there already is a distinction made by fink between different groups of PkgVersions.
    1. Split up Source (package from .info file) vs. Dummy (from Status or VirtPackage)
      1. Create PV::Source which @ISA PV.
        • There should be a method is_source() which returns true for PV::Source only.
        • Temporarily, so that PV's don't suddenly lose the Source methods, make a PV::Dummy which @ISA PV::Source, but returns false for is_source().
      2. Make creators of PVs use the new correct constructors in different packages.
      3. Move methods to PV::Source one-by-one
      4. Modify other classes to respect whether a package is a Source or not (eg: real_install)
      5. Eventually, once everything is ready for it, remove PV::Dummy. Can remove it bit-by-bit by overriding methods with die "Not implemented!".
    2. Split up Parent vs. SplitOff


  • Shlibs needs work: AutoShlibs can wait
  • Module::Build can wait
  • prompt for confirmation before upgrading 'fink reinstall' to 'fink build'? don't care?
  • dmacks: abolish implicit Source? Not worth doing until XMLish Source and Patch
  • Validator:
    • Enforcement of requiring Depends:base-files if install any profile.d scripts (in .deb)? (see fink-devel) not sure we want to do this, so not a blocker
  • fink selfupdate-http
    • Every so often some user complains of not being able to selfupdate-cvs or selfupdate-rsync because of aggressive firewalls/proxies. We could create tarballs (every hour? every CVS commit? every day?) and make them available via HTTP on some server(s) (monipol thought of sourceforge.net, akh suggested master rsync server)
Retrieved from "https://wiki.finkproject.org/index.php?title=Fink:Roadmap:Medium_Term_Goals&oldid=78"