the Fink Wiki - User contributions [en]

Fink:Packaging:gettext

2009-07-24T14:55:59Z

RangerRick: Replaced content with '{{Fink_Header}} Obsolete! {{Fink_Header}} Packaging:gettext gettext'

{{Fink_Header}}

Obsolete!

{{Fink_Header}}

[[Category: Fink|Packaging:gettext]]
[[Category: Fink Packaging|gettext]]

Fink:SelfUpdate

2006-04-06T01:38:43Z

RangerRick:

{{Fink_Header}}

Fink users need up-to-date information about the packages in fink in order to keep their installations up-to-date. Originally, there were two ways of getting this information: either the user relied on "point updates" which are produced at the time of each binary distribution, or the user relied on anonymous CVS access to update their packages from fink's CVS installation.

However, this produced a big load on anonymous CVS (which was also having stability problems to a certain extent), so an alternative method was constructed, which is now urged upon users as the default access method for this information. In short, the current CVS information is downloaded to a master rsync server and propagated to a network of mirror servers. Users then access the information via rsync, from these servers.

The selfupdate repository is kept up to date by a CVS checkout of portions of the fink repository using a registered fink user's account and ssh. The script that runs all this and populates the selfupdate repository is in fink cvs under scripts/selfupdate-server/finkrsyncup.

{{Fink_Header}}

[[Category: Fink|SelfUpdate]]
[[Category: Fink Structure|SelfUpdate]]
[[Category: Fink Commands|SelfUpdate]]

Fink:Updating Another's Package

2006-04-06T01:37:16Z

RangerRick:

{{Fink_Header}}

== Updating Packages that Don't Belong to You ==

People with commits access may update a package for another maintainer without waiting to receive permission if any of the following are true:

# The update is being made for architecture-specific reasons when the listed maintainer doesn't have access to that particular platform and it doesn't break the package on the platform the maintainer ''does'' use.
# The update is of a manifestly trivial nature: e.g. new source URL, a typo in the dependency list, spelling errors in the description fields, etc.
# A week has elapsed without any communication from the maintainer to the mailing lists or the original complainant.

If you do update another maintainer's package this way '''please notify the maintainer'''. Not only is it polite, but some maintainers keep their packages under outside version control, so they'll probably clobber your changes on their next update if they don't know they need to merge them into their own.

[[Category:Fink|Updating Another's Package]]
[[Category:Fink_Packaging|Updating Another's Package]]
[[Category:Fink Policy|Updating Another's Package]]

Fink:Roadmap:0.25 new features:Incremental indexing

2006-04-06T01:36:44Z

RangerRick:

{{Fink_Header}}

===What is it?===

Lets Fink read only new .info files instead of all of them. Also lets Fink load just the part of the package DB that it needs.

===Testing it===

* parameters
** index (write only) or other load (read/write)
** root or non-root
** different versions of fink
** with/without autoindex
** full or partial or proxy run

* race conditions
** run multiple finks at once

* exceptional cases
** rsync: files updated to earlier mtime than last index
** FinkCommander: needs whole DB, caching
** forget and re-load

* missing stuff and dealing with it
** index.db
** proxies.db
** finkinfo dir, or files within

* package has
** proxy stuff (name, version)
** loadable stuff (dumpinfo)

{{Fink_Header}}

[[Category: Fink|Roadmap 0.25 Incremental Indexing]]
[[Category: Fink Roadmap|0.25 Incremental Indexing]]
[[Category: Fink Internals|Incremental Indexing]]

Fink:Policy:Validation

2006-04-06T01:34:39Z

RangerRick:

{{Fink_Header}}

== The Fink Validator ==

The [http://fink.sourceforge.net/doc/users-guide/usage.php?phpLang=en#validate fink validate] command is a tool that checks .info (package description) and .deb (compiled binary) package files for compliance with aspects of [http://fink.sourceforge.net/doc/packaging Fink Packaging Policy] and also detects a variety of common packaging mistakes. Before placing a package on the [http://sourceforge.net/tracker/?atid=414256&group_id=17203 package submissions tracker], you must make sure the .info you submit and the .deb resulting from it have no validation warnings or errors.

If you are just getting starting as a package maintainer, some of the tests may seem arbitrary or excessively nit-picky. The validator is not designed to annoy you (the maintainer) to create un-necessary work, or as a power trip for fink admins, but rather to catch packages that are likely to cause problems for users. They are implemented as a direct result of commonly-observed mistakes in submissions and breakage or general annoyance discussed on the various mailing lists and other venues.

If you are having difficulty solving a validation message, look at other packages similar to yours that validate cleanly. There are usually a variety of solutions to any given problem, depending on the type of package, the user-friendliness of the upstream compiling scripts, etc. Feel free to ask on the mailing lists or IRC channel if you need help.

== Newly-Implemented Tests ==

New tests are created as necessary. Fink admins, developers who handle the package submissions queue, and other users may be running a prerelease version of the fink program that has tests not present in the release version. If someone tells you about a problem in one of your packages as a result of a validation test you don't have, please attempt to fix it. You can't be faulted for not knowing earlier, but...now you know about it. Our goal is to keep the supported fink distributions up to the latest validation standards.

In addition to checks for new features in new fink versions, the following generally-applicable new tests may not be present in all released versions of fink yet:

* The syntax of "Depends" (and similarly-formatted fields) is now checked more strictly.
* There shouldn't be a field named "InfoN".
* "dummy" is not a valid key in the "Type" field.
* We check for a common misuse of the -framework flag in a pkg-config (.pc) data file. This is usually a bug in the upstream version.
* If there are texinfo documentation files, they must be declared in an "InfoDocs" field so that they are linked into the table of contents.
* Different language-version variants of perl and python libraries (-pyXX and -pmXXX packages) must be completely orthogonal; no two variants can have any files in common. Users must be able to install multiple variants concurrently without having conflicts.
* Installed files must not contain references to the pathnames where they were compiled. There are new tests for this problem relevant to compiled python modules (among other filetypes).

{{Fink_Header}}

[[Category: Fink|Policy:Validation]]
[[Category: Fink_Documentation|Policy:Validation]]
[[Category: Fink Policy|Validation]]

Fink:Policy:GCC

2006-04-06T01:31:54Z

RangerRick:

{{Fink_Header}}

== The GCC field ==

A package needs a GCC field if anything in the package is compiled with c++ or g++.

This is a practical guide. For policy information see [http://fink.sourceforge.net/doc/packaging/compilers.php the packaging manual] and [http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg11877.html email to fink-devel] .

=== How to tell if a binary has been compiled with g++ ===

A good way to tell if a binary in your package was compiled with g++ is:

<pre>
nm -g $binary > symbols
c++filt3 < symbols > symbols.filt
diff symbols symbols.filt
</pre>

In most cases, if there is a difference it was compiled with g++ (some exceptions exist involving weirdly named C functions).

=== The script ===

The script [http://vasi.webhop.org/trac/browser/fink/trunk/scripts/gcc-field gcc-field] can check one or more packages to see if they need a GCC field.

To check one package, run it like this:

<pre>
gcc-field $package
</pre>

If it prints anything, the package doesn't have the right field (or is an exceptional case). If it doesn't print anything, you're ok!

You can also check all your packages:

<pre>
gcc-field --maintainer=Vasilevsky
</pre>

Or check a set of files:

<pre>
find ./root-foo | gcc-field -
</pre>

Please run <code>gcc-field --help</code> for details.

{{Fink_Header}}

[[Category: Fink|Policy:GCC]]
[[Category: GCC|Fink Policy]]
[[Category: Fink_Documentation|Policy:GCC]]
[[Category: Fink_Policy|GCC]]

Fink:Packaging:FreeDesktop

2006-04-05T22:42:20Z

RangerRick:

{{Fink_Header}}

==The Problem==

There is a new standard governing menus and maybe some other stuff. Various fink packages in [[Fink:Packaging:KDE|KDE]] and [[Fink:Packaging:Gnome|GNOME]] rely on it and implement subsets of it. As a result, two packages implementing the same functionality (menus for example) conflict because they install their own take on the same standard file in the same standard location. Some portions of the standard rely on env vars that are not set or are set in non-obvious packages. We need a unified package that sets the env vars to "our" standard place and unified packages that supply coalesced KDE/GNOME files. Miga [http://thread.gmane.org/gmane.os.apple.fink.gnome/1323 wrote about it] on fink-gnome-core.

==The Solution==

We need a unified package that sets the env vars to "our" standard place and unified packages that supply coalesced KDE/GNOME files.

===package "xdg-base" (done)===

* Set standard environment variables (via <code>profile.d</code>)
* List as Depends in some basic GNOME and KDE packages:
** shared-mime-info (>= 0.14-9)
** gtk+2? (*TODO*)
** glib2? (*TODO*)
** KDE...um...?

{| border=1
|+ Environment variable
!| [http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html Variable]
!| Linux standard
!| [http://fink.sf.net/pdb/package.php/xdg-base Fink equiv]
|-
| <code>XDG_DATA_HOME</code>
| <code>~/.local/share</code>
| <code>${HOME}/.local/share</code>
|-
| <code>XDG_DATA_DIRS</code>
| <code>/usr/local/share:/usr/share</code>
| <code>%p/share</code>
|-
| <code>XDG_CONFIG_HOME</code>
| <code>~/.config</code>
| <code>${HOME}/.config</code>
|-
| <code>XDG_CONFIG_DIRS</code>
| <code>/etc/xdg</code>
|<code>%p/etc/xdg</code>
|-
| <code>XDG_CACHE_HOME</code>
| <code>~/.cache</code>
| <code>${HOME}/.cache</code>
|}

===package "freedesktop-menus"===

* provide basic menus
** unified gnome/kde?
** custom-written top-level filen, move existing gnome and kde top-level to be sub-menus of it?
* stand-alone pkg or part of "freedesktop"?
** have extensive depends/recommends or just the data files?

{{Fink_Header}}

[[Category: Fink|Packaging FreeDesktop]]
[[Category: Fink Packaging|FreeDesktop]]
[[Category: Gnome|Packaging FreeDesktop]]
[[Category: KDE|Packaging FreeDesktop]]

The Fink Wiki:Roadmap:0.26 goals

2006-04-05T22:40:02Z

RangerRick:

{{Fink_Header}}

* [[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]]
* 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 <code>Description=~/^\[/</code> 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 [[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.

* 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.
** <code>eval `fink dumpinfo -fenv foo | grep =`</code> (works now I think?)
** 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

{{Fink_Header}}

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

The Fink Wiki:Roadmap:0.25 new documentation needs

2006-04-05T22:39:27Z

RangerRick:

{{Fink_Header}}

See also [[Fink:Roadmap:0.25 new features|0.25 new features]]

* Info3

* '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

{{Fink_Header}}

[[Category: Fink|Roadmap 0.25 Documentation]]
[[Category: Fink_Roadmap|0.25 Documentation]]
[[Category: Fink_Documentation|Roadmap 0.25]]

The Fink Wiki:Roadmap:0.24 backports

2006-04-05T22:38:30Z

RangerRick:

{{Fink_Header}}

* <s>BuildDep swapping</s> '''done'''

* <s>ParentEssential fix</s> '''done'''

{{Fink_Header}}

[[Category: Fink|Roadmap 0.24]]
[[Category: Fink_Roadmap|0.24]]

Fink:Roadmap:0.24 backports

2006-04-05T22:38:30Z

RangerRick:

{{Fink_Header}}

* <s>BuildDep swapping</s> '''done'''

* <s>ParentEssential fix</s> '''done'''

{{Fink_Header}}

[[Category: Fink|Roadmap 0.24]]
[[Category: Fink_Roadmap|0.24]]

Category:Fink Trees

2006-04-05T22:12:04Z

RangerRick:

Broad categorizations of Fink package descriptions based on OS (and cryptographic export status).

[[Category:Fink|Trees]]

Category:Fink Structure

2006-04-05T22:11:54Z

RangerRick:

Information about the structure of the Fink project, and its resources.

[[Category:Fink|Structure]]

Category:Fink Roadmap

2006-04-05T22:11:44Z

RangerRick:

The Fink development roadmap.

[[Category:Fink|Roadmap]]

Category:Fink Packaging

2006-04-05T22:09:42Z

RangerRick:

Information supplementing the official [http://fink.sourceforge.net/doc/users-guide/ Fink User's Guide].

[[Category:Fink|Packaging]]

Category:Fink Internals

2006-04-05T22:09:31Z

RangerRick:

Information about the implementation of the <code>fink</code> command and it's associated perl modules.

[[Category:Fink|Internals]]

Category:Fink Infofile Syntax

2006-04-05T22:09:22Z

RangerRick:

A reference for future development and existing infofile syntax.

[[Category:Fink|Info File Syntax]]

Category:Fink Commands

2006-04-05T22:08:11Z

RangerRick:

Fink command-line options.

[[Category:Fink|Commands]]