Re: Feaping Creature-ism in core Debian Packages
On Mon, 30 Aug 1999, Joey Hess wrote:
> Dale Scheetz wrote:
> > is built using debhelper. debhelper will not build (I believe because perl
> > is not installed...heaven forbid that perl be built with debhelper!), so I
> > simply installed the binary-all package.
>
> Yes, debhelper source-depends on perl, since it depends on perl and of
> course it uses itself to build.
Well, I _do_ have perl installed, and here is the build.log from my
attempt:
no utmp entry available, using value of LOGNAME ("root") at /usr/lib/dpkg/controllib.pl line 40.
no utmp entry available, using value of LOGNAME ("root") at /usr/lib/dpkg/controllib.pl line 40.
dpkg-buildpackage: source package is debhelper
no utmp entry available, using value of LOGNAME ("root") at /usr/lib/dpkg/controllib.pl line 40.
no utmp entry available, using value of LOGNAME ("root") at /usr/lib/dpkg/controllib.pl line 40.
dpkg-buildpackage: source version is 2.0.27
no utmp entry available, using value of LOGNAME ("root") at /usr/lib/dpkg/controllib.pl line 40.
no utmp entry available, using value of LOGNAME ("root") at /usr/lib/dpkg/controllib.pl line 40.
dpkg-buildpackage: source maintainer is Joey Hess <joeyh@master.debian.org>
dpkg-buildpackage: build architecture is sparc
debian/rules clean
sh -e debian/fixlinks
touch link-stamp
./dh_testdir
./dh_testroot
./dh_clean link-stamp
rm -f debian/substvars debian/postinst.debhelper debian/postrm.debhelper debian/preinst.debhelper debian/prerm.debhelper
rm -rf debian/debhelper
rm -f -- link-stamp
rm -f debian/files
find . -type f -a \( -name \#\*\# -o -name \*\~ -o -name DEADJOE -o -name \*.orig -o -name \*.rej -o -name \*.bak -o -name .\*.orig -o -name .\*.rej -o -name .SUMS -o -name TAGS -o -name core -o \( -path \*/.deps/\* -a -name \*.P \) \) -exec rm -f {} \;
dpkg-source -b debhelper-2.0.27
no utmp entry available, using value of LOGNAME ("root") at /usr/lib/dpkg/controllib.pl line 40.
no utmp entry available, using value of LOGNAME ("root") at /usr/lib/dpkg/controllib.pl line 40.
no utmp entry available, using value of LOGNAME ("root") at /usr/lib/dpkg/controllib.pl line 40.
dpkg-source: building debhelper in debhelper_2.0.27.tar.gz
dpkg-source: building debhelper in debhelper_2.0.27.tar.gz
dpkg-source: building debhelper in debhelper_2.0.27.tar.gz
dpkg-source: building debhelper in debhelper_2.0.27.dsc
debian/rules build
sh -e debian/fixlinks
touch link-stamp
./dh_clean
rm -f debian/substvars debian/postinst.debhelper debian/postrm.debhelper debian/preinst.debhelper debian/prerm.debhelper
rm -rf debian/debhelper
rm -f debian/files
find . -type f -a \( -name \#\*\# -o -name \*\~ -o -name DEADJOE -o -name \*.orig -o -name \*.rej -o -name \*.bak -o -name .\*.orig -o -name .\*.rej -o -name .SUMS -o -name TAGS -o -name core -o \( -path \*/.deps/\* -a -name \*.P \) \) -exec rm -f {} \;
DH_VERSION=10 perl -MTest::Harness -e 'runtests grep { ! /CVS/ } @ARGV' t/*
t/dh_lin............Can't locate Test.pm in @INC (@INC contains: /usr/lib/perl5/sparc-linux/5.004 /usr/lib/perl5 /usr/local/lib/site_perl/sparc-linux /usr/local/lib/site_perl . /usr/lib/perl5/sparc-linux/5.004 /usr/lib/perl5 /usr/local/lib/site_perl/sparc
-linux /usr/local/lib/site_perl .) at t/dh_link line 2.
BEGIN failed--compilation aborted at t/dh_link line 2.
dubious
Test returned status 2 (wstat 512, 0x200)
FAILED--1 test script could be run, alas--no output ever seen
make: *** [test] Error 2
>
> But I don't understand why you were trying to build debhelper, it is an
I am trying to build all packages that are needed for a build of glibc.
My goal is to determine just what source dependencies actually exist for
these critical core packages, so that they may be properly constructed,
and properly upgraded. Without adequate source dependencies, I saw no
other choice in the matter.
> arch-all package and there's no reason at all to build them when you're
> porting. That's the one thing you get for free when you start a new port,
> after all.
Yes, and that is what I finally used to get past the block.
>
> And yes, perl is built partly with debhelper, but it won't fail if debhelper
> isn't around to build it (you lose md5sums is all).
>
It would be a better design if no package that used debhelper would fail
to build without the existance of debhelper. I see no reason that these
helper programs can't construct a self-contained rules file with none of
the external calls now present. My only objection to this package is that
it automatically makes the rules file depend on the existance of the
debhelper package. This makes the package defacto important rather than
the optional that officially holds as a priority.
> > If you can insert a call to a script into the rules file, you can
> > certainly insert the contents of that script into the same rules file.
>
> Average length of a debhelper program: 55 lines.
> Average number of debhelper programs called per debian/rules file: 27
> Size of the debhelper library: 371 lines.
>
> Estimated growth of a debian/rules file if it included all necessary
> debhelper code inline: 1829 lines.
>
I have absolutely no problems with this. I believe that the rules file
should be self-contained make code, with no outside dependencies. The fact
that this requires similar lines of code to appear in every rules file
doesn't bother me in the least. The ability to go to one place in a Debian
source package to modify package construction processes is a strength that
debmake currently destroys.
> (I'm assumming this would be written in shell; debhelper has been and was
> about the same size back then).
>
> Why is debhelper so big, you ask? Because it's robust and full-featured. Any
> similar replacement will get about this big as it becomes robust and
> full-featured as well.
I have no problem with a robust rules file, only a distributed one.
>
> > I encourage anyone who has used this tool on any of the
> > standard packages to take steps to remove these dependencies from their
> > packages.
>
> Well as far as I'm concerned: use whatever you like. I'm not attached to
> people using debhelper. Actually, I would much like to see a base system
> that could built as an entirely self-contained process.
As I have said many times before, I am _not_ opposed to helper programs.
What I _am_ opposed to is hooking such programs into the rules file in the
fashion that debhelper and other helper programs have used in the past.
Create a self-contained rules file with debhelper, and I would see it as a
useful tool and use it myself. Under the current design, while it makes
creating a new package easily possible for new maintainers (and older ones
too), it removes the need to read policy and maintainer documents, keeping
the new maintainer ignorant about the details of the construction just
performed.
>
> > It seems that we have been allowing perl to creep into critical portions
> > of the installation process without resolving the consequeces of this
> > action. Given that we continue to have recurring discussions about
> > replacing bash with ash or some other POSIX sh, to reduce creeping
> > bashisms, why are there not more outcries against the use of perl in
> > installation and configuration scripting?
>
> I really don't see at all how one follows from the other.
It is not that one follows from the other, but that there are similarities
between the two problems.
>
> Oh, BTW have you noticed that dpkg-dev depends on perl? That it is in fact,
> composed of perl scripts? That you cannot, therefore, build _any_ debian
> package without perl?
Yes, and you can't build dpkg without a whole bunch of non-standard Linux
stuff installed. This just sounds like another example of the problem I am
attemting to describe. How is this a counter argument?
>
> > system construction tools either. Perl may never become a stable language,
> > but even if it does in the future, it surely isn't stable right now, and
> > should not be incorporated into critical system installation processes.
>
> Perl 5 has been around for about 5 years. I think the quote is close to
> "perl 5 has lasted longer than all pervious versions of perl combined"
> (Larry Wall). It's surely a lot more stable than oh, libc.
>
We can't possibly create an installation process without libc, while we
_were_ creating distributions quite well with only shell scripts allowed.
(hell, at one time dpkg was only shell scripts)
My point about perl is that when you integrate more dependencies into the
installation process you automatically create more points of failure.
Allowing the infiltration of perl into installation proceedures
unnecessarily complexifies the process with very little gain, outside
allowing perl programmers to ply their trade. The fact that the upstream
maintainers of perl have shown historic willingness to break interfaces in
order to "improve" perl, suggests that such occurances will happen in the
future, with unknown ramifications.
While the same things can be said about glibc, I don't think this implies
that we should treat perl in the same fashion that we do glibc.
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Reply to: