On Fri, May 25, 2007 at 05:36:34PM +0200, Giorgio Pioda wrote:
> Hello Paul and Damyan
> 
> > On Thu, May 24, 2007 at 11:59:31PM +0300, Damyan Ivanov wrote:
> >> [added the list again]
> >> -=| Giorgio Pioda, Thu, 24 May 2007 21:11:19 +0200 |=-
> >>>> If I were you, I'd try to make "make install" not strip anything,
> >>>> patching if necessary[1]. The problem with dh_install approach is
> >>>> that you have to check carefully if there is something new to
> >>>> install every now and then, which leads to problems (as already
> >>>> seen).
> >>>>
> >>> The world is nice because it is possible to find many different
> >>> opinions...
> >> I see your confusion and I understand it. It is not so good feeling to
> >> try to satisfy contradicting requirements.
> >>
> >> I, personally, will not sponsor a package that replaces a perfectly
> >> working "make install" with broken dh_install usage. Even if
> >> dh_install usage is fixed, I still don't like it. This, of course, does
> >> not mean that nobody else will want to sponsor it.
> >>
> > 
> > Gentlemen,
> > 
> > I am by no means an expert on debian, but as the upstream developer of
> > peless, I have to agree with Mr. Damyan Ivanov on this technical issue.
> > 
> > The history of Computers shows that whenever the same piece of data
> > is stored/maintained in more than one place, they inevitably get out
> > of sync, resulting in bugs and problems.
> > 
> > As the developer of peless, I must insure that "make" and "make install"
> > work properly. I do this indirectly by making sure that configure.ac
> > and Makefile.am are correct. "make" and "make install" control the
> > way peless is built and the way files are copied to their ultimate
> > destinations. "make" and "make install" definitely must be used for
> > distributions other than debian. Now I glean from the discussions
> > you have been having, that if dh_install is used, then essentially
> > the same information must be maintained somewhere else. History
> > shows that this can not be good.
> 
> Ok, then in that case the configure and make could be improved to have a
> clean "nostrip" option which normally is called with
> 
> "make install -s"
> 
> and can be set up in debian/rules together with the noopt option
> 

OK, but first let me understand what I am fixing. What is wrong
with "make install" as it is? There is also a "make install-strip".
I did not do anything special to create these targets; auto* tools
created them. What exactly is wrong with "make install"? Thank you.



-- 
Paul Elliott                       1(512)837-1096
[EMAIL PROTECTED]                    PMB 181, 11900 Metric Blvd Suite J
http://www.io.com/~pelliott/pme/   Austin TX 78758-3117

Attachment: pgpHV5OByPqAt.pgp
Description: PGP signature

Reply via email to