Re: Possible framework for `debmake replacement'
On 27 Feb 1997, Manoj Srivastava wrote:
>> The only advantage of making it a compiler is that is
>> independent from the installed version of the tool. That
>> could be easily solved by defining a well known interface to
>> the utilities.
> The tool should not be required to build a package from the
> sources. I should be able to download the sources, and compile,
> without having this tool in the ``source dependencies''. This, apart
> from version independence, is a good technical requirement, and is
> not impossible to implement.
It can be required, as dpkg is required.
I think that the set of required utilities should be included in the same
package, and perfectly integrated.
debsd perform some operations that should be moved to dpkg (like
checksuming files).
>> I don't see the point in making it a compilerm. It may look
>> nicer, it's like Autoconf... but Autoconf has a different
>> goal. Autoconf can't be an interpreter because one can't
>> count on having autoconf installed on every machine.
> Autoconf is a compiler, yes. But our tool is not. So don't
> restrict us by autoconf's failures. We should not require autoconf
> to be ubiquitously installed. We should also not insist on the new
> tool to be installed to build a package that was created with this
> tool.
I don't see any problem about requiring some utilities... as I said, we
currently require dpkg... =)
>> Then it would be necesary to include a big script that test
>> for everything. Autoconf provides a mean to strip this huge
>> script and only test what the package needs to test.
> Why has this degenrated into discussion of autoconf's
> blemishes?
Because I think that autoconf is a compiler to address problems that we
don't have here.
>> But here, Debian packages are all built in a common environment. And
>> we may require certain uitilities to be there at the moment of the
>> building.
> But requiring the debmake replacement tool is not, and should
> not, be required. It is not now, and we are trying to make package
> build easier, not add a lot of extra requirements gratituously.
>> I think that creating utilities is a more natural way to
>> handle this.
> I do not quite follow this statement.
It's more complex to generate this `compiler'. But this is not so
important.. =)
>> I've read this argument: `With a script compiler you can see
>> and edit the results'... Come on!! Have you ever edited
>> `configure'?
> That is autoconf's problem. If ever we rewrite autoconf, that
> would be very valid. We should make our compiler output easier to
> edit. Remember, this *is* a design goal for us. It may not have
> been one for autoconf developers. Different tool, different goals.
Ok...
>> All changes would be lost when you run autoconf again..!
> Again, that is _autoconf_. Our tool should be required not to
> blow away user changes.
Something like this:
MANPAGES=tool1.1 tool2.1
for i in [ ...... code ]
done
I vote for something like this:
debman tool1.1 tool2.1
or using a config file that reads:
-----
[manpages]
files=tool1.1, tool2.1
-----
(All these implementations are NOT my proposals for this..! =) )
To update to new standards, and preserve user customization, you would
need to replace portions of the code of the script. This means that the
user can't customize the code. And the more logical way to have portions
of code replaced, and to pass parameters is not to `sed' into an script
and use env. variables. The natural way is: external scripts (with a well
defined interface).
> This is why I have been resisting being drawn in too deep into
> implemetation issues: we tend to loose the forest for the trees.
I like to discuss with sample implementations, as you may already have
noted... =)
> I'll be posting a summary of suggestions that I have compiled
> from the list as soon as I'm sure the lists are stable again.
Ok..!
Nicolás Lichtmaier.-
nick@feedback.com.ar
Reply to: