X-Spam-Check-By: sourceware.org
Message-ID: <46781F52.7BDF4B@dessent.net>
Date: Tue, 19 Jun 2007 11:24:18 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: emacs 22.1?
References: <Pine DOT LNX DOT 4 DOT 64 DOT 0706181035280 DOT 5368 AT recycler DOT in-berlin DOT de>  <20070618084646 DOT GK4179 AT calimero DOT vinschen DOT de> <Pine DOT LNX DOT 4 DOT 64 DOT 0706181447040 DOT 5368 AT recycler DOT in-berlin DOT de>  <20070618130035 DOT GN4179 AT calimero DOT vinschen DOT de> <1182194212 DOT 467427 AT alpaka DOT in-berlin DOT de>  <20070618204746 DOT GA1813 AT ednor> <Pine DOT LNX DOT 4 DOT 64 DOT 0706190816340 DOT 16813 AT recycler DOT in-berlin DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

[please take this thread to cygwin-apps!]

Steffen Sledz wrote:

> Is there a suggested build environment (may be a prepared VMware image)?
> Or just installing cygwin base and devel?

There's no standard.  But some things are obvious:

You shouldn't build your packages against a shapshot/unreleased version
of the Cygwin library, since you risk detecting and using features not
present in the current version.

Any link time library dependencies must be accurately reflected in the
"requires:" line of setup.hint.  You can run cygcheck on the binary to
verify.  I think if you use cygport[*] there is even an automatic rule
that checks library dependencies against your setup.hint.

If the package has any --with-foo optional features (usually
corresponding to required external libraries) it's your choice which set
to enable, but the general practice is that you should enable all of
them that correspond to libraries that already exist in the distro.  Or,
if there's an important enough feature corresponding to a lib not in the
distro, you can first independently package the lib on its own, then
enable the feature, then ITP both at the same time.  Additionally, if
the package contains a subpackge library that might be used by other
packages, it should be split off into its own lib- package so that other
packages can install just the library and not the whole enchalada.

There is a whole additional set of guidelines for handing libraries
(such as versioning, package splitting into foo/libfoo/foo-devel,
handling ABI bumps, etc) but for emacs it doesn't sound like these would
be relevant.

[*] cygport is one of the newest packaging methods and isn't currently
mentioned on the setup.html page, but it's essentially a refinement on
the generic-build-script method, so if you understand that then you will
probably get cygport.

> What about file ownership and permissions? Under which user account (uid)
> the packages should be build?

It doesn't matter as setup.exe's tar code doesn't do anything with uid
or permissions when extracting, so you get the default ACLs.  If your
package requires special permissions on some file then it has to be
handled in the postinstall.

> How to mark obsolete packages? In emacs 22.1 leim is integrated. So the
> extra leim package is obsolete.

The general method is to upload an empty (but still valid) .tar.bz2 file
and bump the version number so that the obsolete package is essentially
removed and replaced by nothing.  You can then change its category to
"_obsolete" and it will no longer be visible in setup.

> The old emacs package is neither build using method One nor method Two
> mentioned on http://cygwin.com/setup.html. Is there something to pay
> attention to in the new package to avoid update problems?

Well, that's the kind of thing the maintainer will have to determine. 
:)  Really though, the exact packaging method doesn't matter, and in
fact the methods are only really guidelines anyway.  The important thing
to understand is what will happen to the state of a user's disk before
and after installing a package.  It can be roughly distilled into:

- run any preremove script
- delete all files listed in the manifest
- unpack the new verion's tarball in /, creating new manifest
- run any postinstall(s)

The main concept to grasp is that setup only creates/deletes the files
in the .tar, and it does so unconditionally based strictly on the
manifest, i.e. it removes exactly what it unpacked when the package was
installed.  If there is anything requiring nuance, such as installing a
default config file if one does not exist, or running some kind of
generate-defaults script, then it must be scripted in a postinstall. 
And any files created/deleted by a postinstall will not be "known by"
setup, so either they must be removed explicitly in preremove, orphaned
on the user's PC forever, or manually appended to the manifest by the
postinstall.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/