This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: emacs 22.1?

[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 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


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]