[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Feaping Creature-ism in core Debian Packages

>>"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

        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.


 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*.

 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: