The Fink Wiki:Roadmap:0.26 goals

From the Fink Wiki
Jump to: navigation, search


  • 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
  • make AutoScanpackages default to true (requires that an apt-ftparchive binary be available as part of the default installation).
  • Obsoletes field, to make it easy to get rid of unneeded packages.
    • Eg: foo and foo-ssl exist. Now foo decides to link against the system's SSL, so there's no more need for foo-ssl. In foo.info, we add Obsoletes: foo-ssl 1.2.3-2 . Fink automagically creates a package foo-ssl 1.2.3-2 that is just a dummy depending on the current version of foo, so that foo-ssl users will get foo installed. Fink cleanup could later remove any dummy packages that are left installed but no longer a Depends of any installed package.
    • This requires some indexer support.
    • The token that marks a package as obsolete needs to be in the .deb somehow. Maybe have the Description be "[OBSOLETE: replaced by %N]" where %N is package that contains this Obsolete: field, not the obsoleted packge. Makes it easy for a semi-clueful user to see what's going on. We already use Description=~/^\[/ only for special packages with well-established text, so no off-target effects.
  • 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.
    • eval `fink dumpinfo -fenv foo | grep =` (works now I think?)
    • 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