Re: Feaping Creature-ism in core Debian Packages
Hi,
>>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:
>> If by installation scripts you mean {pre,post}{inst,rm}
>> scripts, then that is a bug, since the packages must only rely on
>> Base/essential packages in those scripts. If you mean intallation
>> scripts as those run by ./debian/rules, never mind.
>>
Dale> Personally I object to perl routines embedded in a rules file,
Hmmm. I guess I differ on this point; since adding perl to my
rules file (or even more obscure packages like texi2html) make the
resulting package better, and less likely to break since it is easier
for me to code.
The difference between our positions comes from the goals: I
am focussed totally on the .deb file, and you are emphasizing a port
or a rebuild situation.
In my eyes, requiring that a build machine be more or less
full feldged development machine with loads of devel packages is not
unreasonable, but obviously you do not feel that way. And I can see
some justification when when thinks of auto builders, since different
packages may require conflicting packages during the build.
Also, Perl is rapidly becoming a standard on most unices, and
it is not unreasonable to expect it on a build platform.
Dale> but the point I was trying to make is that placing perl-base in
Dale> the essential packages creates a "camel's nose"
Dale> situation. Those who use perl are now allowed to do so in
Dale> installation scripts as well as in package build
Dale> circumstances.
As I said, I would consider the build circumstances fair game.
Dale> Now the stage is set for the inclusion of perlisms that aren't
Dale> supported by this essential package, but were available on the
Dale> maintainer's machine when he built the package. Now, even
Dale> though you may have the proper essential packages installed,
Dale> the build fails because some additional feature of perl is not
Dale> available.
As far as I know, there is no requirement that one sticks to
the essential packages for the build. For maintainer scripts, yes,
but not for the build. In the former case, one has to cater for
minimal or initial install situations, where non essential packages
are not present, but one may expect a build machine to be less
feature free. (You are doubtless aware that flex, make, and gcc are
not essential?)
Dale> The maintainer may not even have been aware that they stepped
Dale> ouside the boundries of the essential perl package, and thus
Dale> will not know to include this dependency in any future source
Dale> depends mechanism.
This is easy. If you ``use'' or ``require'' any library, you
have stepped outside the essential package.
======================================================================
__> cat /var/lib/dpkg/info/perl-base.list
/.
/usr
/usr/doc
/usr/doc/perl-base
/usr/doc/perl-base/copyright
/usr/doc/perl-base/changelog.Debian.gz
======================================================================
Hence; specfying source dependencies is not so hard.
>>
>> If you are talking about installing packages, one should
>> either use a (pre-)[1]dependency, or only use essential packages
>> (perl is provided by perl-base) Building make, for example, does
>> require lex and yacc.
>>
Dale> Actually the problem that I ran into with make (which started me down this
Dale> trail) was that it requires texi2html, which comes from the tetex-bin
Dale> package, which requires xlib6g from the xfree86 package. It was this
Dale> dependence of a core package on a large applications package that began to
Dale> cause my skin to itch.
I still do not see it that way. I am not convinced that core
packages need be buildable on a bare bones machine.
>> [1] I think if your pre-inst requires said package, it has to be a
>> pre-dependency.
Dale> Pre-dependencies are known to kill dselect when they form a chain. (dhttp
Dale> has such a pre-depends in slink)
Quite so. But the statement still stands: if your pre-inst
requires said package, it has to be a pre-dependency.
>> A number of my packages provide HTML format documentation (by
>> running texi2html). In my opinion, the advantages of the general user
>> having this documentation justifies the cost of people _building_ the
>> package
Dale> It only justifies the cost of building if that cost is not too high.
Yes.
Dale> Consider a fundamental core program like make. Currently make will not
Dale> build without texi2html, which comes from the tetex-bin package.
Dale> Now, let us assume (probably not the case, but I need a scenerio) that
Dale> tetex-bin uses autoconf to build the source, and depends on a new feature
Dale> from the latest autoconf; but building autoconf requires the newest
Dale> version of make, which can't be built without texi2html.
In a word: cross compile, and bootstrap your machine to a
level that it can be used as a build platform. You don't really have
to use the .deb file, you know; make is a stand alone binary.
Dale> Now, when you realize that to get a functional version of make
Dale> doesn't require the construction of html docs, you see that
Dale> this dependency on texi2html is "artificialy" created by Debian
Dale> documentation policy.
No. I could have built the HTML docs on my machine and added
them to ./debian/html/*; but I chose not to bloat the diff.gz and *I*
chose to use texi2html.
Dale> I can comment out those calls in the rules file, and build a functional
Dale> make package, but such "corrections" are not easy to work into an
Dale> autobuild process. (Debian isn't just for Intel any more)
Are we talking about an initial bootstrap process on a new
port? That is a fairly uncommon situation. Making things work more
easily, and thus with less possibility of a bug, for the most common
case counts for a lot. And Perl does a lot of things easily that one
has to jump through hoops in shell script.
And we should accept a cross compilation process for new
ports. That is a one time process, done by one user. If bootstrapping
a new installation is the issue, I would say that boot strap using
a cross compiler, or build a system using raw binaries -- not .debs,
if you have to.
>>
Dale> Why are we sticking calls to perl routines into a rules file in
Dale> the first place?
>>
>> To make a better package? ;-)
>>
Dale> My point is that making individual packages "better" at the
Dale> expense of the overall package integration process is _not_ the
Dale> path to a superior distribution. We must begin to consider the
Dale> ramifications of these individual improvements as they pertain
Dale> to the "big picture", and not remain tightly focused solely on
Dale> the optimization of individual packages.
I'm sorry. In my opinion, using texi2html to provide HTML docs
for make does make make*.deb a better package, and less likely
to have outdated documentation. I am for making the common case
better and easier, even at the expence of a rare situation faced by
very select group of people *once*.
manoj
--
If you mess with a thing long enough, it'll break. Schmidt
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: