This is the mail archive of the 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: LPRng issues (fwd)

Pavel Tsekov wrote:
> On Wed, 12 Mar 2003, Max Bowsher wrote:
>>> What about including a directory named CYGWIN-PATCHES in the source
>>> tarball ? It should include the setup.hint file and the README file.
>>> This will require a patch I guess.
>>> If I am wrong, please, someone correct me.
>> You are not wrong, but there is more to say:
>> AFAIK, a README is not _required_. Neither is it required (also
>> AFAIK) for setup.hint to be *inside* the tarball (after all, if
>> anyone wants it, they can always grab it from any Cygwin mirror).
> How about this text from
> [ ... ]
> In general, any cygwin-specific "packaging" files -- such as
> cygwin-specific READMEs, a copy of the setup.hint file for your
> package,
> etc. -- should unpack within a /CYGWIN-PATCHES/ subdirectory in your
> sources. Naturally, applying the patch (in reverse, as described
> above)
> would remove these files from the source tree.
> [ ... ]
> I understand the "should" doesn't mean "must" but I think that this
> recommendation should be followed.

A README can be useful. I'm not sure about the value of putting setup.hint
in the tarball, but why not, if you are adding a README anyway.

> Maybe I'm the only one here who
> cannot get the right meaning of the instructions :)

Sounds like you got the meaning exactly.

>> So, he *could* just put up the pure unchanged source tarball, if and
>> only if it builds with "./configure && make" with no options or
>> patches.
>> Now, personally, I think method 2 (script-based) packaging is best,
>> so I'd suggest having a look at the "Method Two" section of
> Yep. I think Method Two simplifies the things a lot and takes care
> for a lot of things like the patch, the files in CYGWIN-PATCHES, etc.
> Once you get used to it and tweak the script it does a very good job.
> For example I first packaged MC using Method One, but now the new
> version uses Method Two and I'm quite happy with it. Also it is quite
> usefull if for some reason one want to compile on multiple platforms
> - you just move the source tarball on the destination platform and run
> the script.

Yes, Method Two packages are very pleasant to work with.


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