the Fink Wiki - User contributions [en]

Fink:Packaging:Obsolete Packages

2012-03-29T09:39:27Z

Fingolfin: /* Mark the package as obsolete */ Explain that obsolete splitoffs should use RuntimeDepends: f-o-p

{{Fink_Header}}

This page explains a new feature available starting in fink-0.26.0

Over time, packages sometimes get renamed or entirely replaced by other packages. The "obsoletes" mechanism provides a way to deal with the migration to the new package-name for users and package maintainers.

==The situation==

Package upgrades sometimes involve changes to the package name, but fink does not have a direct way to specify such an upgrade path. For example, when an old foo-ssl/foo pair is replaced by a single foo (or other variant removal situation), a user may have foo-ssl installed. How does the user know that "new version of foo replaces old foo-ssl" without having foo already installed?

A similar problem may occur when shared-library packages contain a -bin or other userland component and the major libversion changes: how do we indicate the upgrade path from foo1-bin to foo2-bin? This could be used in conjunction with migration to [[Fink:Policy:system-openssl|-unified packages]].

Finally and more generally, a maintainer may decide that a certain package is no longer needed, and its files get redistributed among other packages. How can other packages that need those files and previously depended on the package that formerly contained them be alerted to change to the new dependency?

Note that all these cases involve direct "drop-in" replacements of the old packages. At this time, I do not think "old library versions" are candidates for this system precisely because one cannot assume that simply using a different library-version will always work: by definition, a new library-version means that symbols are likely removed and/or other completely incompatible interface changes have been made. Also, one cannot always change a package's dependency on a lib "in a vacuum": specific lib-versions may be inherited from dependencies (down the dep tree), and changes may require cascading dependency changes (up the dep tree).

==The solution==

When a package "foo" is obsolete and to be replaced by a package "bar", the maintainer needs to do two things in package "foo":

===Provide a clean upgrade path===
Package "foo" must still exist as long as other packages use it and/or users might still have it installed. Therefore, one creates a new revision (or version) of it that Depends on whatever package(s) and version(s) now supply its former contents. A user can thus upgrade from his old "foo" to this new one without having to know to install the different package-name.

This package "foo" would be Type:bundle or else some other dummy package format. If not Type:bundle, remember to create a share/doc/%n/README or touch a file share/doc/installed-files/%n, as packages that do not contain any files are forbidden.

====Handling user-land executable packages====
There might be a reason to keep the actual contents instead of just providing a dummy upgrade package. For example, a certain user-land executable might be in a new package-name but the maintainer wants to keep the old one around for a while. In this situation, one would obviously keep the old package as a real one with contents and not a bundle with Depends on the new one. This does not provide an obvious upgrade path, but the maintainer does not want to make the upgrade mandatory. The best solution might be a DescUsage or DescDetail note about the new package to use instead.

===Mark the package as obsolete===
To mark the package "foo" as obsolete, list "fink-obsolete-packages" in its Depends field. However, if you are making a splitoff obsolete, then you should use
RuntimeDepends: fink-obsolete-packages
BuildDepends: fink (>= 0.32)
instead. Otherwise, building the main package (or any of the non-obsolete splitoffs) will cause fink-obsolete-packages to be installed, which is undesirable. But when using RuntimeDepends, f-o-p gets only installed when a user tries to actually install the obsolete splitoff.

In addition to adding the dependency, you must change the Description field to reflect that the package is obsolete. There are two alternatives here: If your packages has a specific unique successor package 'bar', then use this:
Description: OBSOLETE use package 'bar' instead
If there is no clear successor, use this (and provide the promised extra information in DescDetail)
Description: OBSOLETE use 'fink info %n' to learn more

Once you have done this, Fink automatically treats package "foo" as obsolete in several ways:
* <code>fink cleanup --obsolete-packages</code> will attempt to remove obsolete packages. Due to the upgrade-path dependencies (see above) the user already has the actual new package installed, so the obsolete package is not needed from the user's perspective.
* When a user needs to choose among several alternative packages to satisfy a dependency, obsolete packages are marked as such and are presented last in the list. This encourages the user to choose the modern package and avoid having the obsolete package installed.
* When fink is run in <code>--maintainer</code> mode, an error is generated when a package has a dependency that is preferentially satisfied by an obsolete package. This encourages the maintainer to write dependencies on the modern package, avoids forcing users to install the obsolete package, and helps excise the obsolete package from the dependency tree.
There are some special concerns related to headers packages and other situations where a package that is <code>BuildDependsOnly: true</code> becomes obsolete. If foo-dev is renamed to foo1-dev, foo-dev is obsolete and foo1-dev is a normal package with <code>BuildDependsOnly: true</code>. The whole purpose here is for other packages that have a dependency on the old package-name (foo-dev) to behave "correctly" instead of breaking. Thus, foo-dev has <code>Depends:foo1-dev, fink-obsolete-packages</code>. Ordinarily, a dependency on a BDO package is forbidden, however, it is allowed when the dependant package is marked as obsolete. Note that the obsolete package should still be marked with the same BDO tag as the new package, again so that packages that have dependencies on the old package get the correct BDO signals.

The obsoletes mechanism is for packaging changes, not for changes handled by other means such as Shlibs Policy "new package-name for new install_name" situations. You should ''not'' obsolete a library or headers package when a new major libversion is packaged. That is, if there was foo1-{dev,shlibs} and then foo2-{dev,shlibs} is added, foo1 is still a completely valid package (and indeed some dependants may never be able to convert to using foo2 because the the lib interface may have changed compared to foo1). Therefore, neither foo1-dev nor foo1-shlibs should be marked as obsolete.

{{Fink_Header}}

[[Category: Fink|New Feature Plans Obsoletes]]
[[Category: Fink_Roadmap|New Feature Plans Obsoletes]]
[[Category: Fink_Infofile_Syntax|New Feature Plans Obsoletes]]

Fink:InternetDomains

2011-10-29T13:04:32Z

Fingolfin:

The fink project (and the distfiles subproject) use a number of different URL's and internet domains.

The website for fink was formerly hosted at fink.sourceforge.net, which now points to the current site www.finkproject.org.

Domains:
* finkproject.org
** www.finkproject.org is the [[Fink:Website|website]]
** pdb.finkproject.org is the location of the [[Fink:PackageDatabase|package database]]
** wiki.finkproject.org is the location of the fink Wiki
* finkmirrors.net
** bindist.finkmirrors.net is the location of the [[Fink:ArchiveBrowser|archive browser]] (currently hosted at www.finkproject.org)
** master.us.finkmirrors.net is the master mirror for [[Fink:SelfUpdate|selfupdate via rsync]] (currently hosted at www.finkproject.org)
** distfiles.master.finkmirrors.net is the master mirror for the [[Fink:Distfiles|distfiles project]] (currently hosted at www.finkproject.org)
** the are many international mirror sites of both of the above

TODO: Add information on who can fix issues with DNS entries, should any crop up, or can setup new subdomains.

[[Category: Fink|Internet Domains]]
[[Category: Fink Structure|Internet Domains]]

Fink:Roadmap:0.26 new features

2011-10-29T12:59:37Z

Fingolfin: cleanup

{{Fink_Header}}

* [[Fink:Packaging:Obsolete Packages|Obsoletes]] support
* Enable more than one Notify plugin at once
* Type: -64bit, %lib, and %type_num[] (for building 64bit libs in parallel with 32bit libs)
* new Distribution: field, which behaves like the Architecture: field
* Change allowed filenames for .info file, to: invariant packagename, optionally followed by archname, optionally follwed by distribution, and finally optionally followed by either version or version-revision, each delimited by hyphens.
* <code>fink configure</code> now allows to enable/disable the unstable tree
* <code>--dpkg-status</code> and <code>--all</code> modes for <code>fink cleanup</code>
* <code>--tests</code> mode to utilize <code>InfoTest</code> blocks
** '''on''' Errors are fatal
** '''warn''' Errors turn to warnings
* <code>--validate</code> mode that causes packages to be validated
** '''on''' Errors are fatal
** '''warn''' Errors turn to warning
* Info4 (added in 0.26.2)
{{Fink_Header}}

[[Category: Fink|Roadmap 0.26 New Features]]
[[Category: Fink_Roadmap|0.26 New Features]]

Fink:Website

2011-10-29T12:56:00Z

Fingolfin:

{{Fink_Header}}

The contents of the fink website are stored in our CVS repository. Most portions of the website are constructed by editing XML files, which are subsequently processsed into the files actually used on the website.

TODO: Give more details on the web/html/php vs. XML business.

TODO: Explain about finch.finkproject.org, about how one actually updates the website there (after modifying CVS).

The [[Fink:PackageDatabase|Package Database]] ([[Fink:PackageDatabase|pdb]]) is available at [http://pdb.finkproject.org/pdb/ http://pdb.finkproject.org/pdb/].

TODO: Explain how the PDB and website code tie together?

[[Category: Fink|Web Site]]
[[Category: Fink Structure|Web Site]]

Fink:CVS

2011-10-29T12:35:53Z

Fingolfin:

{{Infobox Project Service Information|
url=https://sourceforge.net/scm/?type=cvs&group_id=17203|
purpose= Store parts of the project's source code (in particular, the "dists" module contains all Fink package).|
maintainer=TODO
}}

Many different portions of the fink project use the fink CVS repository to store files which are maintained by the fink developers and package maintainers. There are several basic levels of commit access to the repository: access can be granted to the website area (web, scripts/installer, fink), to the entire scripts module, and to the basic code areas (website area as well as base-files, mirrors, dists, packages).

Here are the top-level headers in the CVS repository, together with a description of what they are used for.
* '''3rdparty:''' imports of CVS trees from external projects which the fink project plans to modify locally
* '''CVSROOT:''' access control to the CVS repository, maintained by the fink Core group
* '''base-files:''' files for the "base-files" package, a part of fink
* '''dists:''' package descriptions for every distribution starting with 10.2
* '''dlcompat:''' old files for the "dlcompat" library (libdl), which was moved out of fink and into its own fink package (and later became obsolete with the 10.3 distribution)
* '''experimental:''' package maintainers and other coders are invited to use a per-person directory here to make experimental versions of fink materials available for testing
* '''fink:''' files for the "fink" package (the 'fink' package manager programs)
* '''fink/mirror:''' files for the "fink-mirrors" package, a part of fink
* '''fink-maintainertools:''' work in progress for a package of utilities for package maintainers
* '''fink-prebinding:''' files for the "fink-prebinding" program, which has become obsolete with the 10.4 distribution
* '''fix-fink:''' files for the "fix-fink" program, an obsolete program which was used to correct some problems with fink installations during 2002 and 2003
* '''mirrors:''' obsolete (former location of the lists of mirrors used by fink)
* '''packages:''' package descriptions for the 10.1 distribution
* '''scripts/10.4-update:''' a script for updating a 10.3 or 10.4-transitional fink installation to 10.4, along with 12 MB of .deb files used in the update
* '''scripts/bindist:''' scripts for creating the binary files, used by fink's UseBinaryFiles mode, as well as available from the Archive Browser; also the scripts used to create the Archive Browser
* '''scripts/buildfink:''' scripts for an automated build of fink packages
* '''scripts/disfiles:''' script for automated [[Fink:Distfiles|mirroring of source tarballs]]
* '''scripts/installer:''' scripts to build the installer package which lets users install fink without compiling anything
* '''scripts/pdb:''' scripts used to create and update the [[Fink:PackageDatabase|package database]]
* '''scripts/selfupdate-server:''' scripts used by the [[Fink:SelfUpdate|selfupdate server]]
* '''scripts/srcdist:''' scripts used in conjunction with the SourceForge file release system to release the programs fink, fink-mirrors, fink-prebinding, base-files; also to release tarballs of packages to accompany each binary distribution
* '''scripts/xfree86:''' very obsolete utility for getting snapshot of xfree86 development cvs
* '''shared-libraries:''' work in progress on implementing an automated detection of shared library dependencies (pretty much obsolete)
* '''web:''' files for the website (some generated from web/xml, some manually edited here)
* '''web/xml:''' basic location of the files that one actually edits to change the website (see web/xml/README for an explanation)

There are also some virtual CVS modules:
* '''xml:''' the thing to check out for modifying the website (contains web, scripts, and fink)
* '''website:''' the thing to check out for the website contents only

Using CVS:
This example downloads a copy of [checks out] the xml tree:

cvs -d:ext:yourusername@fink.cvs.sourceforge.net:/cvsroot/fink co xml

{{Fink_Header}}

[[Category: Fink|CVS]]
[[Category: Fink Structure|CVS]]

Template:Infobox Project Service Information

2011-10-29T12:14:55Z

Fingolfin: Created page with "{| style="border: 1px solid #6666ff; margin: 0px; padding: 0px; width: 270px; align=right; margin: 3px; float: right;" cellspacing=0 | align="center" colspan=2 style="background-..."

{| style="border: 1px solid #6666ff; margin: 0px; padding: 0px; width: 270px; align=right; margin: 3px; float: right;" cellspacing=0
| align="center" colspan=2 style="background-color: #f0f0ff;" | '''''{{PAGENAME}} Project Service'''''
|-
|- valign="top"
|style="padding:5px;"| '''URL(s)'''
| {{{url|None}}}
|- valign="top"
|style="padding:5px;"| '''Purpose'''
| {{{purpose}}}
|- valign="top"
|style="padding:5px;"| '''Maintainer(s)'''
| {{{maintainer|None}}}
|}<includeonly>[[Category:Project Services]]</includeonly><noinclude>
[[Category:Information templates]]</noinclude>

Fink:Packaging:x86 64

2010-05-06T20:23:50Z

Fingolfin: Removing {{Fink_Header}}

This page contains information about building packages for the x86_64 architecture.

==Fink and x86_64==

Fink allows users to choose either a 32- or 64-bit Fink installation on 10.6 systems with 64-bit capable processors. Most packages do not need to be patched to support 64-bit systems because Finks adds /sw/var/lib/fink/path-prefix-10.6 to the PATH environmental variable before a package is built. This directory contains aliases for commonly used compiler driver names such as cc, gcc, c++, g++, and adds the appropriate -arch flag when invoking them: -arch i386 for 32-bit Fink, -arch x86_64 for 64-bit Fink. Note that -arch is an Apple GCC only flag.

This should be enough for most build systems. However, there are some caveats.

==Autoconf-based build systems==

Autoconf-based systems use the config.guess script to identify the system type; the resulting identification is a triplet cpu-vendor-os. On Mac OS X, these triplets follow the format cpu-apple-darwinX, where cpu is powerpc, i386, or x86_64, and X is the major version outputted by uname -r. Valid examples are i386-apple-darwin9 and x86_64-apple-darwin10.

Depending on the verifications performed by the configure script, it might be necessary to specify on which system type the resulting programs or libraries are meant to run. This is the purpose of the <tt>--host</tt>=system_type parameter. Also, <tt>--build</tt> should be defined whenever <tt>--host</tt> is.

In order to set <tt>--build</tt>, <tt>--host</tt> in <tt>ConfigureParams</tt>, use:

<tt>ConfigureParams: --build=%m-apple-darwin`uname -r | cut -d. -f1` --host=%m-apple-darwin`uname -r | cut -d. -f1`</tt>

or the equivalent in <tt>CompileScript</tt>.

==Carbon==

The [http://developer.apple.com/carbon Carbon API] contains libraries that are 32-bit only as well as libraries that are both 32- and 64-bit. Packages that build against Carbon libraries might need to be restricted to powerpc and i386 architectures (i.e., ''not'' x86_64) if they use functions that are only available in 32-bit format.

==The LP64 data model==

Mac OS X uses the LP64 data model, the same used in Linux. In LP64, <tt>int</tt> is a 32-bit data type, whilst <tt>long</tt>, <tt>long long</tt>, and <tt>size_t</tt> are 64-bit data types. Pointers are 64-bit and cannot be stored in <tt>int</tt> variables. When a program is being compiled for x86_64, GCC automatically defines the <tt>__LP64__</tt> macro — use it in case you need conditional compilation for that architecture. More information is available in [http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/64bitPorting/index.html Apple's 64-bit Transition Guide].

==-mdynamic-no-pic==

In x86_64, GCC's -mdynamic-no-pic flag, which allowed applications not to be position-independent (PIC), is a no operation. This means that in x86_64 code must always be position-independent. See http://lists.apple.com/archives/Darwin-dev/2009/Dec/msg00035.html

==Xcode projects==

The ARCHS build setting can be used to specify a target architecture for an Xcode project as follows:

xcodebuild ARCHS=target_architecture

Valid examples of <tt>target_architecture</tt> include <tt>x86_64</tt>, <tt>i386</tt>, <tt>ppc</tt>. Note that on PowerPC machines Fink expands <tt>%m</tt> as <tt>powerpc</tt> instead of the <tt>ppc</tt> value supported by Xcode.

[[Category: Fink|Packaging:x86_64]]
[[Category: Fink Packaging|x86_64]]

Fink:Packaging:Fink on multiple architectures

2010-05-06T20:16:33Z

Fingolfin: Removing {{Fink_Header}}

Recent versions fink contain support for multiple-architecture distributions (unified .info files) by means of a new "Architecture" field. [[User:Dmrrsn|Dmrrsn]]'s proposal that we adopt this new field starting with the 10.4 tree, and that we get this into released fink versions "very soon", has been implemented.

For ease of initial setup and migration of existing packages to new architectures, this field has a default value of "powerpc, i386"; for packages which are only appropriate for one architecture or the other, a value could be specified. For example, any package using a compiler earlier than gcc-4.0 should have "Architecture: powerpc" added to it. We now have [[Fink:Architecture_powerpc|a wiki page]] to help track tagging with this new field.

(The tags "powerpc" and "i386" are the correct ones coming from uname, which are used in the name of binary-darwin-foo directories. One question is whether we should allow alternates like ppc which fink would translate.)

Note that this mechanism is very flexible: if we ever have a third architecture, we can just add a third tag.

The indexer only indexes those packages whose Architecture field (or its default value) contains the current architecture. That is, "if an Architecture field is present, only index the file if local architecture value is listed".

If a package needs separate info files for different architectures, they can be given names like foo-powerpc.info and foo-i386.info. If the version/revision numbers also need to be included, the name could be foo-powerpc-1.1-1.info and so on. The .info filename is not parsed for any metadata (any *.info will be read). To simplify validation, the location of the archname within the filename is now fixed: the validator accepts the invariant packagename, optionally followed by archname, optionally follwed by distribution, and finally optionally followed by either version or version-revision, each delimited by hyphens.

We have a tag already for the current architecture: %m. This can be used in forming names of patch files, for example. That also means we can use the existing variant mechanisms and shell logic tests to support Platform-dependent differences in a single .info file. Note that compiled packages are not portable among different architectures (the arch string is part of the .deb filename and control-file metadata), and [[User:Dmacks|DMacks]] doesn't think there is a need to worry about "upgrade paths" among platforms. That means a package that contains platform-dependent differences does not need to have a different revision on each platform or contain %m in the Package field.

Vasi pondered using this opportunity to add a Distribution field as well, since it would have the same indexer-exclusion behavior. If we're gonna have a consolidated tree, let's not be pansies about it. If we needed needed Distribution-based differences for a package, we would need a new %-exp token and also a way to have different Revisions for different values (or else some other way to make the Distribution visible in debian metadata). Also need a way to have different subtypes (conditionals on Type key values, for example, a -pyXX package only has XX=2.1 on distro <= 10.3). But until we figure out a syntax, could just say "if you need different revision in different Distributions, make separate .info files. Seems reasonable...

: So should we go for a unified tree right now? Should it include 10.3 as well as 10.4? [[User:Dmrrsn|Dmrrsn]]

[[Category: Fink|Packaging Multiple Architectures]]
[[Category: Fink_Roadmap|Packaging Multiple Architectures]]
[[Category: Fink_Infofile_Syntax|Packaging Multiple Architectures]]
[[Category: Fink_Trees|Packaging Multiple Architectures]]

Fink:FinkProject

2010-05-06T20:12:36Z

Fingolfin: Update

The Fink project is now running its own server at finkproject.org, thanks to the generosity of [http://www.xs4all.nl www.xs4all.nl].

Note: a number of services provided by the server require authentication. THERE IS SOMETHING NONSTANDARD ABOUT OUR CERTIFICATE; HERE IS HOW TO GET YOUR SYSTEM TO RECOGNIZE IT.

Currently, we host the following components of fink on this server:
* This wiki
* The main fink website
* The [[Fink:PackageDatabase|package database]]
* The [[Fink:Distfiles|Distfiles project]] (originally a joint effort with MacPorts (formerly DarwinPorts))
* The [[Fink:ArchiveBrowser|archive browser]]
* The master server for [[Fink:SelfUpdate|selfupdate via rsync]]
* [[Fink:InternetDomains|DNS Hosting]]

Details on [[Server Administration|server administration are here]].

We do not yet have specific plans to migrate the remaining external components to this server:
* The package-submissions and other trackers (presently hosted on SourceForge).
* The mailing lists (presently hosted on SourceForge).
* The CVS repository (presently hosted on SourceForge).
* The file release system (presently hosted on SourceForge).

[[Category: Fink|FinkProject]]
[[Category: Fink Structure|FinkProject]]

Fink:Roadmap:1.0 goals

2010-05-06T20:09:35Z

Fingolfin: Removing {{Fink_Header}}

What could/should be done before fink can be called "1.0"

* all [[Fink:Roadmap:Near Term Goals|Near Term Goals]]

* all [[Fink:Roadmap:Medium Term Goals|Medium Term Goals]]

* see also the [https://sourceforge.net/tracker/?atid=317203&group_id=17203 patch tracker] and [https://sourceforge.net/tracker/?atid=117203&group_id=17203 bug tracker]

* rethink our -ssl policy (see [http://sourceforge.net/tracker/index.php?func=detail&aid=1102917&group_id=17203&atid=367203 Tracker 1102917] )

* implement a possibility to remove unneeded packages (ala debfoster, see [http://sourceforge.net/tracker/index.php?func=detail&aid=593475&group_id=17203&atid=367203 Tracker 593475] )

* reccomends/suggests support in fink (see [http://sourceforge.net/tracker/index.php?func=detail&aid=662397&group_id=17203&atid=367203 Tracker 662397] )

* unstable binary distribution? (see [http://sourceforge.net/tracker/index.php?func=detail&aid=595244&group_id=17203&atid=367203 Tracker 595244] )

* fink option to only use binary packages available (use .deb in preference to whatever is in pdb, even if .deb version isn't in pdb at all)

* rethink our policy on maybe gpg signing info files and/or binary packages.

[[Category: Fink|Roadmap 1.0 Goals]]
[[Category: Fink_Roadmap|1.0 Goals]]

Fink:Roadmap:Medium Term Goals

2010-05-06T20:09:23Z

Fingolfin: Removing {{Fink_Header}}

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 [[Fink:Roadmap:Near_Term_Goals|Near Term Goals]] page.

* [[Fink:Major New Feature Plans:InheritedBuildDepends|InheritedBuildDepends]]

* [[Fink:Major New Feature Plans:XMLish Source and Patch|new Source blocks]]

* more indexing work
** refactor into <code>Indexer.pm</code> 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

* [http://sourceforge.net/tracker/index.php?func=detail&aid=642075&group_id=17203&atid=367203 rethink passwd]

* [http://sourceforge.net/tracker/?func=detail&aid=992093&group_id=17203&atid=117203 Check version dependencies during package upgrade] to avoid (or at least minimize) dep breakage. If foo-dev:depends:foo(=%v-%r), upgrading foo should (but does not currently) trigger an upgrade of foo-dev.
** Moving discussion to bug.

* New license that permits source mirroring but not binary distribution. (see [http://article.gmane.org/gmane.os.apple.fink.devel/10927 openssl-linked packages: need new license type?] on fink-devel)

* 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) —[[User:Msachs|msachs]]
**[http://lingon.sourceforge.net/ 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 [[Fink:Major New Feature Plans:XMLish Source and Patch|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.

* <strike>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.</strike>
** dmacks: I see on #fink you also mentioned installing deps; good idea! Something like:<code>fink install-dependencies [--build] foo</code> or <code>fink install-[build-]dependencies foo</code> (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.
*# Split up Source (package from .info file) vs. Dummy (from Status or VirtPackage)
*## 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().
*## Make creators of PVs use the new correct constructors in different packages.
*## Move methods to PV::Source one-by-one
*## Modify other classes to respect whether a package is a Source or not (eg: real_install)
*## Eventually, once everything is ready for it, remove PV::Dummy. Can remove it bit-by-bit by overriding methods with die "Not implemented!".
*# Split up Parent vs. SplitOff

* Shlibs needs work: '''AutoShlibs can wait'''
** unpredictable depends?
** [https://sourceforge.net/tracker/index.php?func=detail&aid=1249916&group_id=17203&atid=117203 read-from-debs] issue
* [http://sourceforge.net/tracker/index.php?func=detail&aid=998741&group_id=17203&atid=317203 Module::Build] '''can wait'''
* prompt for confirmation before [http://permalink.gmane.org/gmane.os.macosx.fink.devel/10863 upgrading] 'fink reinstall' to 'fink build'? '''don't care?'''
* dmacks: abolish implicit <code>Source</code>? '''Not worth doing until [[Fink:Major New Feature Plans:XMLish Source and Patch|XMLish Source and Patch]]'''
* Validator:
** Enforcement of requiring Depends:base-files if install any profile.d scripts (in .deb)? (see [http://thread.gmane.org/gmane.os.macosx.fink.devel/11210 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)

[[Category: Fink|Roadmap Medium Term Goals]]
[[Category: Fink_Roadmap|Medium Term Goals]]

Fink:Roadmap:Near Term Goals

2010-05-06T20:09:11Z

Fingolfin: Removing {{Fink_Header}}

This page tracks features or bug fixes that should be implemented in the next fink release (or soon afterwards). This mostly includes high priority or easy-to-implement tasks. For other features please refer to the [[Fink:Roadmap:Medium_Term_Goals|Medium Term Goals]] page.

See also the [https://sourceforge.net/tracker/?atid=317203&group_id=17203 patch tracker] and [https://sourceforge.net/tracker/?atid=117203&group_id=17203 bug tracker]

=== Todo ===

* Update docs: [[Fink:Roadmap:New_documentation_needs|New documentation needs]]
* cirdan, drm: dist up
* test FinkCommander patch for incremental indexing
* x11 user vs. sdk issue

[[Category: Fink|Roadmap Near Term Goals]]
[[Category: Fink_Roadmap|Near Term Goals]]

Fink:Roadmap:New documentation needs

2010-05-06T20:08:58Z

Fingolfin: Removing {{Fink_Header}}

See also new major features in releases [[Fink:Roadmap:0.25 new features|0.25]], [[Fink:Roadmap:0.26 new features|0.26]], [[Fink:Roadmap:0.27 new features|0.27]], and [[Fink:Roadmap:0.28 new features|0.28]]

* Info3/Info4

* 'fink cleanup' (in fink.8 but need to add to web docs)

* AutoShlibs

* fast scanpackages with apt-ftparchive, including AutoScanpackages

* SkipPrompts

* --maintainer (in fink.8 but need to add to web docs)

* remove old 'fink list --tree=foo' documentation, add 'fink --trees=foo,bar command'.

* new DocFiles/Files abilities
** Conditionals
** subdirs/recursion
** Mention the allowed wildcards that are used and useful (* ? (any others--curly-braces or square brackets?)) so we don't accidentally break useful existing functionality...conditionals interferes with some uses of curly-braces
** Mention backtick scripts?

* --log-output and --logfile (in fink.8 but need to add to web docs)

* 'fink plugins' lists checksum algorithms

[[Category: Fink|Roadmap New documentation needs]]
[[Category: Fink_Roadmap|New documentation needs]]
[[Category: Fink_Documentation|New documentation needs]]

Fink:Downloads

2010-05-06T20:08:12Z

Fingolfin: Removing {{Fink_Header}}

The download statistics at Sourceforge.net may not be fully reliable, but they are the best measure we have of how many people might be using fink.
Files other than the installer files are mirrored other places, so the Sourceforge statistics are misleading. But we will attempt to keep track of Sourceforge downloads of installer files.

For any currently downloadable file, the current download count is available on the Files page at sourceforge.net/projects/fink. But for formerly available files, we need to record the final download count here.

=== 10.4 ===

Fink-0.8.1-Intel-Installer.dmg is still available. (MD5 = 38c5837f8beb1ea96a04f9ca1ceba800; see [[Security]])

Fink-0.8.1-PowerPC-Installer.dmg is still available.

Fink-0.8.0-Installer.dmg was downloaded 272907 times.

=== 10.3 ===

Fink-0.7.2-Installer.dmg is still available.

Fink-0.7.1-Installer.dmg was downloaded 216556 times.

Fink-0.7.0-Installer.dmg was downloaded 131165 times.

=== 10.2 ===

Fink-0.6.4-Installer.dmg is still available.

Fink-0.6.3-Installer.dmg was downloaded 37077 times.

Fink-0.6.2-Installer.dmg was downloaded 102211 + 37132 times (the file was listed twice on the sourceforge page).

Fink-0.6.1-Installer.dmg was downloaded 25403 times.

Fink-0.5.3-Installer.dmg was downloaded 57596 times.

Fink-0.5.2-Installer.dmg was downloaded 33665 times.

Fink-0.5.1-Installer.dmg was downloaded 70330 times.

Fink-0.5.0a-Installer.dmg was downloaded 41410 times.

=== 10.1 ===

Fink-0.4.0-Installer.dmg is still available.

fink-0.3.2a-installer.dmg.gz was downloaded 90804 times.

fink-0.3.1-installer.dmg.gz was downloaded 24337 times.

fink-0.3.0-installer.dmg.gz was downloaded 23158 times.

{{Fink_Header}}

[[Category:Fink]]

Fink:About

2010-05-06T20:07:07Z

Fingolfin: Removing {{Fink_Header}}

== What is Fink? ==

Fink is a project that wants to bring the full world of Unix Open Source software to Darwin and Mac OS X. As a result, we have two main goals. First, to modify existing Open Source software so that it will compile and run on Mac OS X. (This process is called porting.) Second, to make the results available to casual users as a coherent, comfortable distribution that matches what Linux users are used to. (This process is called packaging.) The project offers precompiled binary packages as well as a fully automated build-from-source system.

To achieve these goals, Fink relies on the excellent package management tools produced by the Debian project - dpkg, dselect and apt-get. On top of that, Fink adds its own package manager, named (surprise!) fink. You can view fink as a build engine - it takes package descriptions and produces binary .deb packages from that. In the process, it downloads the original source code from the Internet, patches it as necessary, then goes through the whole process of configuring and building the package. Finally, it wraps the results up in a package archive that is ready to be installed by dpkg.

Since Fink sits on top of Mac OS X, it has a strict policy to avoid interference with the base system. As a result, Fink manages a separate directory tree and provides the infrastructure to make it easy to use.

== Why use Fink? ==

Five reasons to use Fink to install Unix software on your Mac:

# Power. Mac OS X includes only a basic set of command line tools. Fink brings you enhancements for these tools as well as a selection of graphical applications developed for Linux and other Unix variants.
# Convenience. With Fink the compile process is fully automated; you'll never have to worry about Makefiles or configure scripts and their parameters again. The dependency system automatically takes care that all required libraries are present. Our packages are usually set up for their maximum feature set.
# Safety. Fink's strict non-interference policy makes sure that the vulnerable parts of your Mac OS X system are not touched. You can update Mac OS X without fear that it will step on Fink's toes and vice versa. Also, the packaging system lets you safely remove software you no longer need.
# Coherence. Fink is not just a random collection of packages, it is a coherent distribution. Installed files are placed in predictable locations. Documentation listings are kept up to date. There's a unified interface to control server processes. And there's more, most of it working for you under the hood.
# Flexibility. You only download and install the programs you need. Fink gives you the freedom to install XFree86 or other X11 solutions in any way you like. If you don't want X11 at all, that's okay too.

To learn more, go to the [http://fink.sourceforge.net/ Fink home page].

[[Category: Fink|About]]

Template:Fink Header

2010-05-06T20:03:01Z

Fingolfin: Hiding {{Fink_Header}} globally