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: [Review - not yet] Re: [ITP] tree

Igor Pechtchanski wrote:
> Hmm, I guess it's not that important.  I was just going by what's on
> <>, which clearly states that applying the
> patch *in reverse* should get you the original sources...

hmm, isn't it the case?!

> > > 3) Any particular reason you have the make and install logs in
> > >    CYGWIN-PATCHES?  Also, the make log contains a warning that looks
> > >    suspicious, and the install log shows that "make install" will install
> > >    files directly into /usr/bin, rather than to a subdirectory.  Also,
> > >    "make install" will not put the Cygwin-specific README in the right
> > >    directory.
> >
> > historical. AFAIK some people have been doing this for "documentation
> > purpose" while building packages. The log files may be helpful in
> > identifing possible problems that someone may observe on his local
> > installation.
> True.  It's usually a good idea, though, to be able to install somewhere
> outside of the main tree (e.g., to recreate the package without polluting
> your system)...  I'm not sure how important it is that a package is able
> to do this.

personally I'm not "required" to put the build logs into the tree.
That's right. 

What do the others mean. I haven't followed the list for "some while"
(no comments on this please ;). So I'm for sure out-of-sync regarding
the "commen behaviour"?!

> I agree, that's why method 2 became popular, since you don't have to
> change the Makefiles for some of the Cygwin-specific stuff.  But if you
> stick with method 1, the users should be able to fully install the package
> using "make install"...

now, I'd like to take method 2, but the package does not provide and
sophisticated autoconf suite, only the raw Makefile. And actually for
one .c file this is ok ;)

> Well, I think changing the prefix from /usr/local to /usr is a pretty
> serious change, in a sense that someone familiar with the package and
> wanting to install it on their system will download it, run "make; make
> install", and get the packages in /usr/bin instead of /usr/local/bin where
> they would expect them.  IMO, it deserves a mention in the port notes, but
> I'm not going to hold up the release of a package because of this.

agreed. But don't we consider *all* packages that are installed from
setup.exe to be "system packages" and hence reside underneath the
system /usr mount point. In contrast to those who are compiled and
build by users on their own, which usually go to /usr/local?!?!

I changed the same semantics for Apache. Apache usualy has its
instllation layout into /usr/local/apache and we addopted the
"cygwin-way" to Apache's layout config file to reflect that it is then
"a system package".

> Well, I don't have any 4G+ files on my system, but it's easy to see that
> anything with size over 4G will be displayed incorrectly.
> In fact, most of the LINUX_BIGFILE code should be turned on, except that
> the types are wrong in some places ("long long" instead of off_t), and
> Cygwin has no such thing as "struct stat64" - its "struct stat" is 64-bit
> already.

ok, I'll give it a try... let's see how far I get.

> I'll point out that some of the types in "struct _info" are all wrong for
> Cygwin (mode should be mode_t, uid should be uid_t, gid should be gid_t,
> and size should be off_t).

ok, I'll consider this too.

> Cool.  Let me know when I can download a new version.

I'll give it a try ASAP.

Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf, NRW, Germany

phone: +49.211.74845.0
fax: +49.211.74845.299

Version: GnuPG v1.2.2 (Cygwin)


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