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 > > For example, one of the next things I want to do with peless is > to make sure peless properly publishes its .pot file as the first > step toward making peless multi-lingual. When I do this, I will > adjust the auto* control files to make sure that "make" and "make install" > do the RIGHT THINGS(tm). But you seem to be telling me that if dh_install > is used, that files relevant to dh_install must also be adjusted. > This has to be bad. The same data being managed in 2 places, by 2 different > people. > > I am by no means a debian expert, but it seems to me from what I have > been able to glean from this discussion that dh_install is associated > with a fundamental software management design error. This could be > important with packages more critical than peless. > > I've already set back to "make install" the install mechanism, and the first test was OK. I'll upload to my web space the recompiled package as soon as I'll get half an hour of time in front of my sid-workstation, probably during the week-end. At this time I expect the package to be mature. For multilingual support, as far as the make install will be used, I don't expect big problems. cheers Giorgio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
