WSS v3 Feature definitions (feature.xml) files contain a section that points to files that do most of the heavy lifting of a Feature: <ElementManifests />. This section is where you specify your element manifest files that contain CAML markup that is processed as instructions upon Feature activation. These element manifest files are deployed using the <ElementManifest> element.

However there is a lesser known element that you can use in this same location to your advantage. The <ElementFile /> element, also a child to the <ElementManifests /> element tells SharePoint about other files that are part of the Feature. What kind of files would you put in here? Things such as master pages, page layouts, images, style sheets, Web Part definition files, etc. The Feature doesn't do anything with these files... it just is made aware that they "belong" to the Feature.

"But I'm already using images in my Feature without this and I'm not having any problems... why do I need it?" Good question...

When you package everything up in a WSS solution package you list your Feature's definition file within the manifest.xml file (using the <FeatureManifests /> node) which contain the instructions to SharePoint of what to do with the files within the package (*.wsp). If you have additional files that go along with your Feature, you should be listing them in the manifest.xml file as well using something like <TemplateFiles /> or <RootFiles /> (the former is preferred). But, if you listed all the files that were part of the Feature using the <ElementFile /> nodes within the Feature definition, you wouldn't have to list them here. Why? Because SharePoint will look at the definition and see those are files that are part of the Feature itself so the solution framework will deploy those as well.

Take the following for example. This is a sample Feature that provisions a mater page, page layout, preview images for each, a stylesheet and an image. The element manifest file provisions all these files as uncustomized instances in the a Publishing site.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="D56F0D2D-0107-424d-AA0D-7120329A23E6"
         Title="ACME: Provisioning Master Pages and Page Layouts"
         Hidden="FALSE"
         Scope="Site"
         Version="1.0.0.0">

  <ElementManifests>
    <ElementManifest Location="elements.xml" />
    <ElementFile Location="MasterPages\ACMETmp.master" />
    <ElementFile Location="MasterPages\ACMEMasterPreviewTmp.gif" />
    <ElementFile Location="Styles\ACMETmp.css" />
    <ElementFile Location="Styles\ACMETmp.gif" />
    <ElementFile Location="PageLayouts\ACMEPressTmp.aspx" />
    <ElementFile Location="PageLayouts\ACMEPressPreviewTmp.gif" />
  </ElementManifests>
    
</Feature>

Now, the manifest.xml file for the solution package is quite simple as it only points to the Feature definition within the packaged WSP file:

<?xml version="1.0" encoding="utf-8" ?>
<Solution xmlns="http://schemas.microsoft.com/sharepoint/"
          SolutionId="7DFC3075-45C0-4946-9E5F-CA6BBC749C64"
          DeploymentServerType="WebFrontEnd"
          ResetWebServer="FALSE">
  <FeatureManifests>
    <FeatureManifest Location="ACMESite\feature.xml"/>
  </FeatureManifests>
</Solution>

Consider this approach when building Features... it saves you a lot of headaches when packaging up your Features.