Fink:NewMaintainer

2010-04-14T17:20:37Z

Nieder: changed defunct link to new file provided by danielj

{{Fink_Header}}

== DRAFT ==

If you'd like to maintain software within Fink, we'd love to have your help.

Note that this guide is designed for those who would like to become official Fink packages with full developer privileges, and who are committed to continued maintenance of their packages.

Here's how to start:

=== Learn about packaging software with Fink ===

* If you don't yet have Fink installed, you should [http://fink.sourceforge.net/download/index.php?phpLang=en install it].
* If you're not comfortable using Fink yet, read the [http://fink.sourceforge.net/doc/users-guide/index.php User's Guide].
* Learn the basics of packaging with the [http://fink.sourceforge.net/doc/quick-start-pkg/index.php Packaging Tutorial].
* Read and '''understand''' the [http://fink.sourceforge.net/doc/security/index.php Security Policy]
Once you know the basics, use the following sources for reference:

* The [http://fink.sourceforge.net/doc/packaging/index.php Packaging Manual]
* Some useful [http://fink.sourceforge.net/doc/porting/index.php OS X Porting Tips]
* [[The_Fink_Wiki|This wiki]]

=== Choose some software to package ===

If you already have a program in mind, that's a great place to start. Otherwise, you can check our auto-generated list of [http://pdb.finkproject.org/pdb/nomaintainer.php packages without maintainers]. Also, try the list of [[Fink:Orphaned|packages being orphaned]] ''NOTE: Under construction''.

Remember to make sure the program you chose is not already in fink, by trying
fink list mypackage

Also search the [http://sourceforge.net/tracker/?atid=414256&group_id=17203&func=browse Package Submission Tracker] to make sure you don't duplicate somebody else's work.

=== Create your first package ===

Following the guides you read earlier, create a .info file for your package, and possibly a .patch file as well. A good way to start can be copying an existing .info file, and modifying it to fit your package.

The most important thing to do is to '''test''' and '''validate''' your package. Once you've made your .info file, put it in your local or unstable tree (for example, <tt>/sw/fink/dists/local/main/finkinfo/mypackage.info</tt>). Then build it and validate it:

fink validate /path/to/mypackage.info
fink build mypackage
fink validate /sw/fink/debs/mypackage_1.0-1_darwin-powerpc.deb

If any of the above commands shows you problems, you must fix them before submitting your package. Fink cannot accept packages that don't validate. Even apparently minor problems can become major headaches when they interact with thousands of other packages on thousands of users' computers.

If you are using <code>fink-0.25.x</code> or later then you can perform the commands above automatically, as well as check that your package doesn't install files directly into the filesystem rather than into the .deb archive by running the following:

fink -m --build-as-nobody rebuild mypackage

If you performe this step before submission, your package will get accepted sooner.

Should you need help with packaging, you can ask questions on the [http://fink.sourceforge.net/lists/fink-devel.php fink-devel mailing list]. You can also try asking developers on the #fink IRC channel on irc.freenode.net .

If you use BBEdit or TextWrangler there is a [http://snaggledworks.com/fink/FinkModule.plist Language Module] that offers field highlighting.

A syntax highlighting file for [http://nedit.org NEdit] is also [http://snaggledworks.com/fink/Fink-5.1.pats available].

=== Submit your package ===

If you don't already have an account with [http://sourceforge.net SourceForge.net], you'll need to create one before submitting your package.

Your package can be submitted at the [http://sourceforge.net/tracker/?atid=414256&group_id=17203&func=browse Package Submission Tracker]. Remember to attach the .info and .patch files. Make sure to mark the submission as "Undergoing Validation". And please, '''ensure that your package validates'''.

Notes:

*If your package is currently maintained by someone else, especially someone with commit access, you may get your update through faster if you contact the maintainer directly.
*If you are submitting a new revision or new version of an exiting package then please set the Category appropriately. This will expedite validation of your package.
*If your package is a new lib_version, e.g. <code>foo2</code> when <code>foo1</code> is already in Fink, please use the "Updated lib_version..." Category rather than "Updated Version...", as these require some special care.

'''Important:''' You ''must'' read whatever email account to which you have attached your sourceforge.net account so that you can see when a developer comments on your package, or you ''must'' visit your tracker items and check up on them. Otherwise your submission will sit in the tracker until it is deleted or taken over by somebody who is willing to stay engaged with it.

The Fink project doesn't have enough people to edit submitted packages: that is incumbent on the submitter. Moreover, it is a better learning process when the submitters stay engaged with their submissions and do the updates themselves.

=== Find a mentor (optional) ===

''NOTE: The mentoring system is currently unfinalized''

Because of the large number of submissions we receive, it's easy for some of them to be missed. Personal attention can help prevent this, so it can be a good idea to find a mentor who will follow your progress through your packaging efforts. You can start looking for a mentor [[Fink:Mentoring|here]].

=== Continue packaging, and maintaining your packages ===

A Fink developer should usually maintain more than one package. These packages aren't just constructed once, but have to be kept up to date, as new versions are released and bugs are found. This is the most important part of development, so be sure not to neglect it.

=== Be promoted! ===

Once you've shown your ability to package software and maintain your package, other developers will take notice. One of them will nominate you to the Fink Core Group, who will make the final decision to give you developer privileges.

Congratulations on making it this far, and thanks for contributing to Fink!

{{Fink_Header}}

[[Category:Fink|Maintainer New]]
[[Category:Fink Packaging|Maintainer New]]

Fink:default freetype and pango

2009-09-01T14:03:16Z

Nieder: fix typo in pango1-xft2-ft219 %v

Our gnome-related library packages in the unstable trees are being
migrated to the latest releases (gnome2.24 and associated
dependencies). First, this will obviously involve lots of packages
being updated, so if something doesn't build, don't bother reporting
it until after selfupdating, but then please check if it's been
reported and *do* report if not. But of course don't bother reporting
without specific information about the package and the actual full
error messages.

I'm working "up the tree" starting at glib2, ft219, and RangerRick
bringing along the cairo world and other stuff of his. We're cascading
the dependencies to keep users from getting too much of a mixed bag of
gnome versions (i.e., the new %v of atk1 will require the latest %v of
glib2, not just the minimum glib2 that it claims to accept).

I will test some end packages maintained by others and make
adjustments if I find build problems for the new gnome libs, but don't
plan to do a full overhaul of the whole distro to cascade the latest
dependencies or to remove no-longer-needed flags. In general, the new
stuff will reduce the dependency tree, not add new inherited deps as
far as I can tell.

One major change is that freetype219 now also makes its headers and
other compile-time files available in the "default" locations. If one
sets the freetype219* dependencies to be >=2.3.7-4, one can remove the
-I, -L, and PKG_CONFIG_PATH settings for %p/lib/freetype219* paths
that had previously been required. The install_name and actual
location of the lib is the same (buried) in freetype219-shlibs, so
there is no foward/backward compatibility problem at runtime. The
headers and especially the .la are also still present in the buried
location, so previously-built packages that somehow encoded those
paths are still okay too (especially .la dependency_libs). Unless we
have some other reason to change install_name (and therefore create a
new headers package-name), this buried thing will always need to be
there for compatibility. At that time, we can cascade dependency
changes on it and put the actual things *only* in the default paths.

The old freetype2 (and -hinting) package is completely unused as far
as I can tell. I looked at updating it to the latest, now that the new
version is it's apparently compatible again), but the cascading became
a mess (on the scale of the pangocairo project, involving nearly every
package that uses ft, not just the main library set) to avoid mixing &
matching the different freetype locations and potentially conflicting
package combinations of them. Didn't see the need, since pangocairo
got us completely converted to ft219 dependencies.

pango1-xft2-ft219-dev will also (soon, once I make sure we got it
"right" in freetype219:) make itself available in the default
locations and we can stop using special path flags for it, while
retaining its buried files as well for compatibility.

I do not understand fontconfig, so will leave it to RangerRick (its
maintainer) and others to figure out whether it can be unburied, or
whether there are substantial numbers of packages that are expecting
"something else" to be visible in the default paths.

Important dependencies as part of the upgrade:
*freetype219 (and freetype219-shlibs) >= 2.3.7-4
*pkgconfig >= 0.23
*pango1-xft2-ft219-dev (and pango1-xft2-ft219-shlibs and pango1-xft2-ft219) >= 1.22.0-3

[[Category: Fink]]
[[Category: Fink Packaging]]
[[Category: Gnome]]