[ANNOUNCE] util-linux-ng 2.13-rc1

[ANNOUNCE] util-linux-ng 2.13-rc1

[Karel Zak]

 The first util-linux-ng 2.13 release candidate is available at

    ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/v2.13/


 Thanks to all who help with util-linux resuscitation:

    H. Peter Anvin
    Ian Kent

 and contribute to this project:

    Arkadiusz Miskiewicz       Matthias Koenig
    Cliff Wickman              Mike Frysinger
    David Brownell             Pádraig Brady
    David Miller               Radek Biba
    Jason Vas Dias             Ram Pai
    Kay Sievers                Stepan Kasal
    Luciano Chavez             Steve Grubb
    Marco d'Itri               Valerie Henson
    Martin Schlemmer


 Feedback and bug reports, as always, are welcomed.

	Karel



Util-linux-ng 2.13 Release Notes
================================

Release highlights:
------------------

 mount(8) doesn't include NFS client code anymore. Don't forget to
 install nfs-utils 1.1.0 or newer with /sbin/[u]mount.{nfs,nfs4}.

 mount(8) doesn't include filesystem detection code anymore. You
 have to compile --with-fsprobe={blkid,volume_id}, and libblkid
 (e2fsprogs) or libvolume_id (udev >= v110) is required.

 mount(8) supports new relatime, context, fscontext, and defcontext
 mount options.

 losetup(8) supports command line option "-a" to list all used loop
 devices, '-s' to print a device name if "-f" and a file argument
 are present, and "-r" to create a read-only loop device.

 fdisk(8) Sun label support has been improved. fdisk(8) is also able
 to warn about detected GPT (fdisk doesn't support GPT).

 taskset(1) is independent on hardcoded NR_CPUS. chrt(1) supports
 SCHED_BATCH scheduling policy.

 The package build system is now based on autotools. The build system
 supports  separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
 SUID_LDFLAGS). For more details see the README file

 hwclock(8) supports command line option --rtc=<path> and /dev/rtc0
 device. --systohc functionality has been improved, and it doesn't cause
 a 500ms inaccuracy each time it is used.

 Audit system support (--with-audit) has been added to hwclock(8) and
 login(1).

 SELinux support (--with-selinux) has been added to mkswap(8) and
 mount(8).

 The setarch(8) upstream has been merged with util-linux-ng.


Fixed security issues:
---------------------

 CVE-2007-0822 - mount(8) allows local users to trigger a NULL
                 dereference and an application crash
 CVE-2006-7108 - login(1) omits PAM account validation when auth is
                 skipped


Changelog:
---------

agetty:
	add 'O' escape code to display domain name
	check gethostname() return value
blockdev:
	add BLKFRAGET/BLKFRASET ioctls
	cleanup usage() and update man page
build-sys:
	add AC_GNU_SOURCE
	add Automake option dist-bzip2
	add missing files
	add SUID_CFLAGS
	add SUID_LDFLAGS
	add support for audit
	amend .gitignore
	call automake after autoconf
	cleanup architecture conditionals
	cleanup sys-utils/ rdev symlinks
	configure.am selinux support cleanup
	declare SUID_CFLAGS and SUID_LDFLAGS as precious
	do not build convenience libraries in lib/
	do not kick off AM_CFLAGS by SUID_CFLAGS
	do not play with DEFS, use AM_CPPFLAGS
	do not set with_foo twice
	do not use internal Autoconf variables
	do not use wildcards in EXTRA_DIST
	factor out common parts from mount/Makefile.am
	fix HAVE_NCURSES
	fix ifdef ENABLE_WIDECHAR usage
	fix linking when ncurses is built with --with-termlib=tinfo
	fix README filenames and add missing files to EXTRA_DISTs
	fix the example configure call in README
	fix the final message of autogen.sh
	in configure.ac, change "po" -> "$srcdir/po"
	in the clean targets use "find ... | xargs rm -f"
	let configure instantiate the misc-utils/*.pl scripts
	make the getopt example directory relative to datadir
	merge adjacent AC_CONFIG_HEADERS and AC_CONFIG_FUNCS calls
	minor fixes in configure.in
	mount/Makefile.am tiny cleanup
	mount/Makefile.am tiny cleanup II
	move -D flags to *_CPPFLAGS
	move the optimization flags to AM_CFLAGS
	--prefix defaults to /usr
	remove aclocal.m4 from SCM
	remove AC_PROG_RANLIB
	remove config.h.in from VCS
	remove config/include-Makefile.am from EXTRA_DIST
	remove DEFAULT_INCLUDES workaround
	remove -fomit-frame-pointer
	remove generated autotools stuff from git
	remove po/Makevars.template from EXTRA_DIST
	remove swapargs.h, move the tests to main configure.ac
	rename to -ng, change maintainer name
	replace AC_TRY_* by AC_*_IFELSE
	s/AC_HELP_STRING/AS_HELP_STRING/
	set DISTCHECK_CONFIGURE_FLAGS in top-level makefile
	simplify "clean" in tests/Makefile.am
	update po/POTFILES.in
	use dist_example_DATA
	use dist_noinst_DATA to work around the bug with dist_man_MANS
	use dist_noinst_HEADERS in include/Makefile.am
	use dist_usrbinexec_SCRIPTS in misc-utils/Makefile.am
	check exit status of autotools
cal:
	fix a segfault and -3m highlighting
	ifdef cleanup, non-curses/tempcap code fixes
	widechar code cleanup
cfdisk:
	build-sys defines HAVE_RPMATCH, not HAVE_rpmatch
	fix stupid typo in GPT checker call
chsh:
	remove tailing wihit-spaces and use PATH_BSHELL
col:
	getwchar() errors shouldn't be hidden
ddate:
	fix compiler warnings
docs:
	add the DEPRECATED file
	clean up TODO file and add a new resuest for 2.14
	fix info about devel/master branchs
	fix URL and typos in README.devel
	refresh AUTHORS file
	remove deprecated section from README
	update AUTHORS file
	update TODO file
fdisk:
	add GPT detection code
	add MAC label detection
	cleanup full disk detection code
	fix "differ in signedness" compiler warnings
	fix "type qualifiers ignored on function return type"
	Makefile.am refactoring
	many significant improvements and fixes to Sun label handling
	move duplicate stuff from fdisk*label.h to fdisk.h
	use unsigned long long instead int for sectors
getopt:
	remove old unused files
hexdump:
	don't use memset with zero lenght
hwclock:
	add --rtc=<path> option and support for /dev/rtc0
	add support for audit system
	fix --systohc sets clock 0.5 seconds slow
	make ggc happy and check return values from fgets, read and write
	remove tailing white-spaces and clean up clock.h
ipcs:
	add new tests for ipcs limits
	add regression test for output headers
	fix typo in Semaphore headers
	max total shared memory in kbytes instead pages
login:
	add audit support
	add IPv6 support
	add regression test for IP address checking code
	attempt to run if it has no read/write access to its terminal
	close PAM session after failed pam_setcred
	improve work with signals
	keep syslog useful for end of PAM session.
	login's timeout can fail
	omits PAM account validation when auth is skipped (CVE-2006-7108)
	remove triiling white-spaces
	update 32bit utmp correctly on 64bit system
look:
	fix problem with !isalnum() words
	remove tailing white-spaces
losetup:
	add a new option -s
	add -a option to list all used loop devices
	add long options and fix man page
	add support read-only loops
	add to man page info about deprecated cryptoloop
man pages:
	add "AVAILABILITY" section
mcookie:
	remove non-linux code
misc-utils:
	add scriptreplay manpage
	remove old cal test
mkfs.cramfs:
	cleanup HAVE_ macros usage
	fix a way how mkfs works with empty files
	remove hardcoded limit for directories
mkswap:
	add regression test
	automatically add selinux label to swapfile
	avoid mkswap usage on already mounted device
	gcc happy: unsigned long usage
	fix libuuid usage in mkswap
more:
	fix file descriptor leak
mount:
	add note about /etc/mtab unreliability to mount.8
	add note about fcntl/ioctl unreliability on NFS to mount.8
	add -s and -f and note to man page for external mount helpers
	add simple (printf-like) debug routine and --debug option
	add support for context, fscontext and defcontext selinux mount options
	add support for mixed usage of SPECes
	add support for mtab "uhelper" option
	avoid duplicate entries in mtab when mount -f
	call /sbin/mount.<type> also when mounting without "-t"
	clean up getfs* (fstab.c) interface
	clean up info about NFS in mount.8
	doesn't rpc_pipefs and nfsd on umount -a
	do not treat arm/sparc specially.
	don't umount sysfs when running umount -a
	fix -fv so that it doesn't incorrectly spit out an error that nothing was done.
	fix has_* functions (CVE-2007-0822)
	fix list logic in update_mtab
	fix memory usage in update_mtab
	fix mtab_lock
	fix typo in error message
	fsprobe: add libvolume_id support
	fsprobe: add libvolume_id support to configure.ac
	fsprobe: make fsprobe_get_devname functions more generic
	fsprobe: remove mount_guess_fstype.{c,h}
	fsprobe: remove non-blkid code
	fsprobe: rename files to fsprobe_*
	fsprobe: rename the rest of API routines to fsprobe_*
	fsprobe: use blkid cache only when really necessary
	getfs_* (fstab) interface has to work with canonicalize()
	kill mount_guess_rootdev
	loop device race condition
	needs to handle special mountprog even on guessed file systems.
	parse SPEC before search in fstab
	relative atime support
	remove all NFS code
	remove nfsmount() from sundries.h
	rewrite getfs_by_specdir() without mem leaks
	shared-subtree support
	update mtab correctly when mount --move
	use encoded labels for volume_id
	use growable string for options
	use loop= option when mounting by /sbin/mount.<type>
	use realloc for xstrconcat functions
	use verbose mode instead debug mode
namei:
	fix logic and infinite loop of symlinks
	new regression test
newgrp:
	add support for /etc/gshadow
	check result from getgrnam() more carefully
partx:
	add man pages for addpart, delpart and partx
po:
	rename mount/mntent.c to mount/mount_mntent.c
	typo in french translation of mount error.
	update po files
	vipw doesn't use rpmatch, all translations have to use y/n
raw:
	add file with udev rule example
	don't accept raw0 as a target name
	move the raw command to /sbin
	update man page (about dd and O_DIRECT)
schedutils:
	add support for SCHED_BATCH
	define SCHED_BATCH when compile with old glibc
	remove extra hyptens from man pages
	taskset is independent of hardcoded NR_CPUS max
	fix ionice build on sparc
setarch:
	add NLS support
sfdisk:
	fix "differ in signedness" compiler warnings
	fix "may be used uninitialized" compiler warnings
	setting default geometry values
swapon:
	cleanup PATH_ macros and tailing white-spaces
	does not correctly deal with symlinks
	fix swapon headers and syscalls
	simplify an #if
sys-utils:
	added setarch command
	add note about obsolete ramsize option to rdev.8
	fix man page headers
	move some man pages from category 8 to 1
tests:
	add basic infrastructure for regression tests
	add cal -1 test
	add cal -3 test
	add cal -y test
	add expected outputs for cramfs
	add functions for label, uuid and fstype detection
	add hwclock systohc test
	add library for LD_PRELOAD to manipulate with time() in tests
	add lock_mtab() performance and reliability test
	add look test for words with separator
	add missing header
	add mkfs.cramfs tests
	add more variants to {mount,fstab}-by-{label,uuid,devname}
	add mount by devname from fstab
	add mount by devname test
	add mount by devname with label in fstab
	add mount by devname with uuid in fstab
	add mount by label from fstab test
	add mount by LABEL test
	add mount by label with devname in fstab
	add mount by label with uuid in fstab
	add mount by UUID from fstab test
	add mount by UUID test
	add mount by uuid with devname in fstab
	add mount by uuid with label in fstab
	add mount /dev/symlink test
	add mount --move test
	add mount -o remount test
	add return code
	add simple helper that returns info about system
	add support for fstab modification
	add support for suid programs
	add swapon by devname test
	add swapon by UUID test
	add test for /sbin/mount.<type> call
	add ts_log and --verbose support
	add ts_ok and ts_failed
	cleanup blkid cache after test device deinitialization
	code refactoring -- new ts_device_init function
	code refactoring -- new ts_skip_nonroot function
	code refactoring -- new ts_udev_loop_support function
	enable mtablock test when uid=0 only
	fix argv[] usage in mnt_test_sysinfo.c
	fix dependence on blkid
	fix Makefile.am (add missing tests)
	fix ts_fstab_add function
	"if [...]" clean up
	make clean need to remove diffs and outputs
	pass all arguments to ts_init, add ts_has_option function
	refresh mtablock output in expected/ directory
	simplify devices usage
text-utils:
	fix the more command compilation against termcap
tools:
	add codecheck-config that checks for {HAVE,ENABLE}_ orphans
vipw:
	fix permissions (600->400) for edited /etc/[g]shodow files
wall:
	fix O_NONBLOCK usage
misc:
	Clean up pagesize/PAGE_SIZE usage.
	clean up realpath.[ch] includes and macros
	execl() should be use NULL not 0

-- 
 Karel Zak  <kzak@redhat.com>

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Christoph Hellwig]

On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
>  mount(8) doesn't include filesystem detection code anymore. You
>  have to compile --with-fsprobe={blkid,volume_id}, and libblkid
>  (e2fsprogs) or libvolume_id (udev >= v110) is required.

Sorry, but it's really annoying to pull in a filesystem-specific devel
package for that.  Having a library is fine, but please move the library
into util-linux so it's always available without another dependency.  That
way xfsprogs could for example drop it's own detection library aswell.

>  The package build system is now based on autotools. The build system
>  supports  separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
>  SUID_LDFLAGS). For more details see the README file

And this is really dumb.  autotools is a completely pain in the ass and
not useful at all for linux-only tools.

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[David Miller]

From: Christoph Hellwig <hch@infradead.org>
Date: Wed, 4 Jul 2007 09:42:11 +0100

> On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> >  mount(8) doesn't include filesystem detection code anymore. You
> >  have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> >  (e2fsprogs) or libvolume_id (udev >= v110) is required.
> 
> Sorry, but it's really annoying to pull in a filesystem-specific devel
> package for that.  Having a library is fine, but please move the library
> into util-linux so it's always available without another dependency.  That
> way xfsprogs could for example drop it's own detection library aswell.

I totally agree with Christophe, this dependency is a complete
pain for trying to do util-linux-ng development.  I meant to
complain about this myself.

> >  The package build system is now based on autotools. The build system
> >  supports  separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> >  SUID_LDFLAGS). For more details see the README file
> 
> And this is really dumb.  autotools is a completely pain in the ass and
> not useful at all for linux-only tools.

I second this sentiment as well.  It's not like we expect this stuff
to get used on other systems at all, and the only thing it's getting
used for really is to detect the awful external blkid/volume_id
dependencies.

I totally think this stuff can and should be completely eliminated.

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

On Wednesday 04 July 2007, Christoph Hellwig wrote:
> On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> >  mount(8) doesn't include filesystem detection code anymore. You
> >  have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> >  (e2fsprogs) or libvolume_id (udev >= v110) is required.
>
> Sorry, but it's really annoying to pull in a filesystem-specific devel
> package for that.  Having a library is fine, but please move the library
> into util-linux so it's always available without another dependency.

ugh, moving libraries which are already actively maintained by other core 
projects into util-linux is so not a good idea (ignoring the fact that it'd 
easily be a pita/waste for distro maintainers)

> That 
> way xfsprogs could for example drop it's own detection library aswell.

i dont really think this is dependent on util-linux at all.  nothing is 
stopping xfsprogs from depending on udev or e2fsprogs now.

> >  The package build system is now based on autotools. The build system
> >  supports  separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> >  SUID_LDFLAGS). For more details see the README file
>
> And this is really dumb.  autotools is a completely pain in the ass and

not really at all.  hand written build systems are a constant source of pain 
for distribution maintainers and people trying to cross-compile (and the one 
that was in util-linux had many problems in both these areas).

> not useful at all for linux-only tools.

incorrect.  linux changes over time as does the kernel/libc/architecture 
api's.  look at the old util-linux build system -- it had a crappy hand 
written configure script to try and detect all these different issues.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Andreas Dilger]

On Jul 05, 2007  12:41 -0400, Mike Frysinger wrote:
> On Wednesday 04 July 2007, Christoph Hellwig wrote:
> > Sorry, but it's really annoying to pull in a filesystem-specific devel
> > package for that.  Having a library is fine, but please move the library
> > into util-linux so it's always available without another dependency.
> 
> ugh, moving libraries which are already actively maintained by other core 
> projects into util-linux is so not a good idea (ignoring the fact that it'd 
> easily be a pita/waste for distro maintainers)

Some distros (Debian and SuSE I think) split the e2fsprogs libraries
into separate packages so that you are not depending on "e2fsprogs",
but rather "libuuid" and/or "libblkid".

> > That way xfsprogs could for example drop it's own detection library aswell.
> 
> i dont really think this is dependent on util-linux at all.  nothing is 
> stopping xfsprogs from depending on udev or e2fsprogs now.

In fact, Eric Sandeen and I discussed splitting the xfsprogs "libdisk"
(or similar, it detects RAID geometry for DM/MD/etc) into a standalone
library so that e2fsprogs could use it.  The only issue is the increased
maintenance and packaging of separate libraries.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Karel Zak]

On Thu, Jul 05, 2007 at 12:41:59PM -0400, Mike Frysinger wrote:
> On Wednesday 04 July 2007, Christoph Hellwig wrote:
> > On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> > >  mount(8) doesn't include filesystem detection code anymore. You
> > >  have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> > >  (e2fsprogs) or libvolume_id (udev >= v110) is required.
> >
> > Sorry, but it's really annoying to pull in a filesystem-specific devel
> > package for that.  Having a library is fine, but please move the library
> > into util-linux so it's always available without another dependency.
> 
> ugh, moving libraries which are already actively maintained by other core 
> projects into util-linux is so not a good idea (ignoring the fact that it'd 
> easily be a pita/waste for distro maintainers)

 Yes. We have good experience with libblkid and libvolume_id. This
 concept is nothing new (see current RHEL, FC, Suse, ...). The change
 is that we've removed old, useless and unmaintained FS detection code
 from util-linux.

 I think move the library to util-linux is really bad idea. A better
 idea is detach libblkid or libvolume_id (or both) from e2fsprogs/udev
 and create an independent libfsprobe library and use everywhere
 (e2fsprogs, udev, util-linux) this library only.

> > >  The package build system is now based on autotools. The build system
> > >  supports  separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> > >  SUID_LDFLAGS). For more details see the README file
> >
> > And this is really dumb.  autotools is a completely pain in the ass and

 Well, Adrian Bunk added autotools stuff to util-linux during his work
 on v2.13. This stuff has been fixed and stabilized in util-linux-ng
 v2.13.

 I'm not fanatical autotools protagonist, but it seems useful in
 util-linux. We will see...

 I'm ready to change or fix arbitrary thing in util-linux-ng, but I
 always need a real reason -- bug report, new feature, or so. This
 discussion is about impressions and feelings only.

> > not useful at all for linux-only tools.
> 
> incorrect.  linux changes over time as does the kernel/libc/architecture 
> api's.  look at the old util-linux build system -- it had a crappy hand 
> written configure script to try and detect all these different issues.

 Right. The autotools provides more features that portability only.

    Karel


-- 
 Karel Zak  <kzak@redhat.com>

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Matthew Wilcox]

On Thu, Jul 05, 2007 at 11:30:20PM +0200, Karel Zak wrote:
> > > >  The package build system is now based on autotools. The build system
> > > >  supports  separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> > > >  SUID_LDFLAGS). For more details see the README file
> > >
> > > And this is really dumb.  autotools is a completely pain in the ass and
> 
>  Well, Adrian Bunk added autotools stuff to util-linux during his work
>  on v2.13. This stuff has been fixed and stabilized in util-linux-ng
>  v2.13.
> 
>  I'm not fanatical autotools protagonist, but it seems useful in
>  util-linux. We will see...
> 
>  I'm ready to change or fix arbitrary thing in util-linux-ng, but I
>  always need a real reason -- bug report, new feature, or so. This
>  discussion is about impressions and feelings only.

No, it's based on long, hard and painful experiences attempting to debug
the fuckups that autoconf creates when it goes wrong.

-- 
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Jeff Garzik]

Christoph Hellwig wrote:
> On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
>>  The package build system is now based on autotools. The build system
>>  supports  separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
>>  SUID_LDFLAGS). For more details see the README file
> 
> And this is really dumb.  autotools is a completely pain in the ass and
> not useful at all for linux-only tools.


A myth.  It is quite useful for packagers, because of the high Just 
Works(tm) factor.  After porting an entire across several revisions of a 
distro, the autotools-based packages are the ones that work out of the 
box 90% of the time.

The other 90% of _my_ time comes from annoying people who roll their own 
Makefile/build solution, which the packager has to then learn.

It's just not scalable for people to keep building their own build 
solutions.

	Jeff

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Gerd Hoffmann]

Jeff Garzik wrote:
> Christoph Hellwig wrote:
>> And this is really dumb.  autotools is a completely pain in the ass and
>> not useful at all for linux-only tools.
> 
> A myth.  It is quite useful for packagers, because of the high Just
> Works(tm) factor.  After porting an entire across several revisions of a
> distro, the autotools-based packages are the ones that work out of the
> box 90% of the time.

And the 10% where it doesn't work it is a real pain to figure what goes
wrong due to the completely unreadable Makefiles generated by autotools.
 After all they are not Makefiles, they are shellscripts embedded into
Makefiles.

> The other 90% of _my_ time comes from annoying people who roll their own
> Makefile/build solution, which the packager has to then learn.

Well, it's not *that* hard to write makefiles which follow the usual
gnuish conventions, so stuff like "make DESTDIR=/tmp/buildroot install"
works just fine.  That isn't a reason to use autotools.  Especially as
people get that wrong *even with* autotools from time to time ...

cheers,

  Gerd

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Jeff Garzik]

Gerd Hoffmann wrote:
> Jeff Garzik wrote:
>> Christoph Hellwig wrote:
>>> And this is really dumb.  autotools is a completely pain in the ass and
>>> not useful at all for linux-only tools.
>> A myth.  It is quite useful for packagers, because of the high Just
>> Works(tm) factor.  After porting an entire across several revisions of a
>> distro, the autotools-based packages are the ones that work out of the
>> box 90% of the time.
> 
> And the 10% where it doesn't work it is a real pain to figure what goes
> wrong due to the completely unreadable Makefiles generated by autotools.
>  After all they are not Makefiles, they are shellscripts embedded into
> Makefiles.
> 
>> The other 90% of _my_ time comes from annoying people who roll their own
>> Makefile/build solution, which the packager has to then learn.
> 
> Well, it's not *that* hard to write makefiles which follow the usual
> gnuish conventions, so stuff like "make DESTDIR=/tmp/buildroot install"
> works just fine.  That isn't a reason to use autotools.  Especially as
> people get that wrong *even with* autotools from time to time ...

It's not _just_ makefiles, though.  Packaging systems know what to do 
with configure scripts, and automatically plug that into their systems, 
e.g. with rpm's %configure, %make_install, etc.

Having ported an entire distro, the time savings with autotools [OR 
ANOTHER STANDARD BUILD/CONFIGURE SYSTEM] are very real.  Similarly, the 
time sink with each project doing its own home-rolled build/configure 
system is also very real.

	Jeff

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Joel Becker]

On Fri, Jul 06, 2007 at 11:01:07AM +0200, Gerd Hoffmann wrote:
> And the 10% where it doesn't work it is a real pain to figure what goes
> wrong due to the completely unreadable Makefiles generated by autotools.
>  After all they are not Makefiles, they are shellscripts embedded into
> Makefiles.

	Do not mistake the use of autoconf with automake.  automake
generates the unreadable Makefiles.  You can quite easily create a
useful Makefile yourself and use autoconf to select installation
locations, detect features of older/newer libcs, etc.  See
http://oss.oracle.com/projects/makebo/ for an example of a build system
that doesn't use automake, but allows for autoconf to do build-time
configuration (an example user of makebo is ocfs2-tools, see
 http://oss.oracle.com/projects/ocfs2-tools/src/trunk/).
	And if you think that all packages should Just Work on all
Linuxen, with out any build-time detection, try determining the
differing udev layouts of FC6, FC7, Debian, Ubuntu, SuSE9, SuSE10, etc.
Or where manpages go.  The %configure of RPM specfiles and the
dh_installman of debian packages handle this for you...often because
they can use expected behavior of your build system.  What about
futexes?  Older systems don't have them.  Gotta detect that.

Joel

-- 

"I'm drifting and drifting
 Just like a ship out on the sea.
 Cause I ain't got nobody, baby,
 In this world to care for me."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Gerd Hoffmann]

Joel Becker wrote:
> On Fri, Jul 06, 2007 at 11:01:07AM +0200, Gerd Hoffmann wrote:
>> And the 10% where it doesn't work it is a real pain to figure what goes
>> wrong due to the completely unreadable Makefiles generated by autotools.
>>  After all they are not Makefiles, they are shellscripts embedded into
>> Makefiles.
> 
> 	Do not mistake the use of autoconf with automake.  automake
> generates the unreadable Makefiles.  You can quite easily create a
> useful Makefile yourself and use autoconf to select installation
> locations, detect features of older/newer libcs, etc.

Sure.  I have some projects using autoconf only.  90% of the projects
use both though, autoconf-only is quite rare these days (used to be
different because autoconf was the first ...).

> 	And if you think that all packages should Just Work on all
> Linuxen, with out any build-time detection, try determining the
> differing udev layouts of FC6, FC7, Debian, Ubuntu, SuSE9, SuSE10, etc.

s/build/run/ time check IMHO.  Otherwise things blow up if the user
upgrades fc6 to 7 ...

> Or where manpages go.

/usr/share/man everythere, since years.  Maybe except Debian because
they first discuss 5 years how to handle that ;)

> What about
> futexes?  Older systems don't have them.  Gotta detect that.

Sure, there are some things left you might want to check for even for
linux-only projects.  If it is only whenever some library is installed.
 autoconf will do that, sure.  It's still quite some overkill in many
cases IMHO.  On smaller projects the configure script can easily take
more than 80% of the tarball size ...

cheers,
  Gerd

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On Monday 09 July 2007, Gerd Hoffmann wrote:
> Joel Becker wrote:
> > 	And if you think that all packages should Just Work on all
> > Linuxen, with out any build-time detection, try determining the
> > differing udev layouts of FC6, FC7, Debian, Ubuntu, SuSE9, SuSE10, etc.
>
> s/build/run/ time check IMHO.  Otherwise things blow up if the user
> upgrades fc6 to 7 ...

API's change, ABI's dont
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Jan Engelhardt]

On Jul 4 2007 00:11, Karel Zak wrote:
>newgrp:
>	add support for /etc/gshadow
>	check result from getgrnam() more carefully

Hm, gshadow looks like it is really obsolete. (There is no such file anymore in
suse releases since a long while. Previously, gshadow was filled with all the
groups that existed.)


	Jan
-- 

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[H. Peter Anvin]

Jan Engelhardt wrote:
> On Jul 4 2007 00:11, Karel Zak wrote:
>> newgrp:
>> 	add support for /etc/gshadow
>> 	check result from getgrnam() more carefully
> 
> Hm, gshadow looks like it is really obsolete. (There is no such file anymore in
> suse releases since a long while. Previously, gshadow was filled with all the
> groups that existed.)
> 

gshadow is used when you have groups which have passwords, which is very
rare in practice but permitted in theory.

	-hpa

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[DervishD]

    Hi Karel :)

 * Karel Zak <kzak@redhat.com> dixit:
>  The package build system is now based on autotools. The build system
>  supports  separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
>  SUID_LDFLAGS). For more details see the README file

    If you want to have configurable installation directories and
configurable settings for building but with the pain of autotools, you
can give "mobs" a try if you want. You will find in my homepage (see my
signature below). If you find it so much big and/or you think you will
be changing a pain for another pain, I can help porting.

    Anyway, if you don't like mobs or you just don't want to try it,
that's fine, but please don't use autotools, it doesn't make much sense
for a linux only project, since you will be using only the "directory
choosing" part of autotools. Maybe a hand made script will help (and I
can help with that, too) if you just want to have selectable directories
and CFLAGS support...

    And thanks for util-linux-ng, I was waiting for them :))

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Nix]

On 4 Jul 2007, DervishD stated:
>     Anyway, if you don't like mobs or you just don't want to try it,
> that's fine, but please don't use autotools, it doesn't make much sense
> for a linux only project, since you will be using only the "directory
> choosing" part of autotools. Maybe a hand made script will help (and I

Oh, yeah, great, another hand-rolled build system. That's *juwt* what
those of us who have autotools working well (with config.site's that
do all we need and then some) are looking forward to.

There are advantages to standardization, you know. A *lot* of
autobuilders know how to make autoconf-generated configure scripts jump
through hoops. I was downright *happy* when util-linux was
autoconfiscated: I could ditch the code to handle automatic
configuration of yet another one-package hand-rolled build system.

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Bodo Eggert]

Nix <nix@esperi.org.uk> wrote:
> On 4 Jul 2007, DervishD stated:

>>     Anyway, if you don't like mobs or you just don't want to try it,
>> that's fine, but please don't use autotools, it doesn't make much sense
>> for a linux only project, since you will be using only the "directory
>> choosing" part of autotools. Maybe a hand made script will help (and I
> 
> Oh, yeah, great, another hand-rolled build system. That's *juwt* what
> those of us who have autotools working well (with config.site's that
> do all we need and then some) are looking forward to.
> 
> There are advantages to standardization, you know. A *lot* of
> autobuilders know how to make autoconf-generated configure scripts jump
> through hoops. I was downright *happy* when util-linux was
> autoconfiscated: I could ditch the code to handle automatic
> configuration of yet another one-package hand-rolled build system.

Standardisation is good, but autotools (as they are used) usurally isn't. It
tests for the availability of a fortran compiler for a C-only project, checks
the width of integers on i386 for projects not caring about that and fails to
find installed libraries without telling how it was supposed to find them or
how to make it find that library.

Configuring the build of an autotools program is harder than nescensary;
if it used a config file, you could easily save it somewhere while adding
comments on how and why you did *that* choice, and you could possibly
use a set of default configs which you'd just include.

The Makefiles generated by autotools is a huge mess, if autotools got it
wrong (again!), fixing them requires editing a lot of files.

I'm really really happy if I read 'edit Makefile.conf and run make...'.
-- 
No matter which way you have to march, its always uphill. 

Friß, Spammer: n@kqYYs.7eggert.dyndns.org mlygzw.k@d.7eggert.dyndns.org
 cDmOEZ@z-luqs.7eggert.dyndns.org .-@IfuiUgj.7eggert.dyndns.org

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[DervishD]

    Hi Bodo :)

 * Bodo Eggert <7eggert@gmx.de> dixit:
> Nix <nix@esperi.org.uk> wrote:
> > On 4 Jul 2007, DervishD stated:
> >>     Anyway, if you don't like mobs or you just don't want to try it,
> >> that's fine, but please don't use autotools, it doesn't make much sense
> >> for a linux only project, since you will be using only the "directory
> >> choosing" part of autotools. Maybe a hand made script will help (and I
> > 
> > Oh, yeah, great, another hand-rolled build system. That's *juwt* what
> > those of us who have autotools working well (with config.site's that
> > do all we need and then some) are looking forward to.
> > 
> > There are advantages to standardization, you know. A *lot* of
> > autobuilders know how to make autoconf-generated configure scripts jump
> > through hoops. I was downright *happy* when util-linux was
> > autoconfiscated: I could ditch the code to handle automatic
> > configuration of yet another one-package hand-rolled build system.
> 
> Standardisation is good, but autotools (as they are used) usurally isn't.

    Usually, by picking other's project configure.in and tweak blindly.

> It tests for the availability of a fortran compiler for a C-only
> project, checks the width of integers on i386 for projects not caring
> about that and fails to find installed libraries without telling how
> it was supposed to find them or how to make it find that library.

    My favourite is when the project doesn't honor --*dir options. Or
when the project breaks badly if you put some files in different places
by using configure options... That's good standarization.

> Configuring the build of an autotools program is harder than nescensary;
> if it used a config file, you could easily save it somewhere while adding
> comments on how and why you did *that* choice, and you could possibly
> use a set of default configs which you'd just include.

    Looks like CMake...

> I'm really really happy if I read 'edit Makefile.conf and run make...'.

    Again, this looks like CMake...

    I share your view entirely.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Nix]

On 5 Jul 2007, DervishD spake thusly:
>  * Bodo Eggert <7eggert@gmx.de> dixit:
>> Standardisation is good, but autotools (as they are used) usurally isn't.
>
>     Usually, by picking other's project configure.in and tweak blindly.

You'd think they'd never heard of autoscan...

>     My favourite is when the project doesn't honor --*dir options. Or
> when the project breaks badly if you put some files in different places
> by using configure options... That's good standarization.

That's a broken project, I'd say. But you have a point, which is that
autoconf does too little, and automake plugs the gaps badly (and let's
not even talk about the abomination which is libtool).

>> Configuring the build of an autotools program is harder than nescensary;
>> if it used a config file, you could easily save it somewhere while adding
>> comments on how and why you did *that* choice, and you could possibly
>> use a set of default configs which you'd just include.
>
>     Looks like CMake...

That's cool :) thanks to KDE using it everyone's autobuilders are having
to adapt to cmake anyway, and it's not hard and you only have to do it
once.

>> I'm really really happy if I read 'edit Makefile.conf and run make...'.
>
>     Again, this looks like CMake...

:)

My only real grouch with cmake is that the authors have invented a
language with so bloody many capital letters in it. Looking at cmake
macros makes my eyes bleed even more badly than looking at the mass of
involuted nested brackets in configure.ac's, and that's a difficult
thing to do. (It's less portable than autoconf-generated configure
scripts but most of autoconf's portability tests are for long-dead
systems anyway, and as you said util-linux of all projects doesn't give
a damn. I don't really care if software isn't portable to an Interactive
box --- EOLed in 1992 --- or a SunOS 4.0 or HP-UX 8 box.)

There's a good reason most text is lowercase. Even Lisp moved to
lowercase a long time ago...

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Bernhard Walle]

* Nix <nix@esperi.org.uk> [2007-07-05 22:42]:
> 
> My only real grouch with cmake is that the authors have invented a
> language with so bloody many capital letters in it. 

The real problem I see with cmake is that you need to have cmake
installed on the build system. While cmake itself isn't the problem,
often, it also depends on the version of cmake that is installed. The
good idea about auto* tools is the idea that you don't need to install
any tools to build, just to develop. A POSIX shell and Perl should be
installed everywhere ...

Maybe the problem becomes less important in a few years if everyone
has cmake installed and it's more "stable" in terms of adding new
features.



Thanks,
   Bernhard

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Nix]

On 5 Jul 2007, Bernhard Walle stated:

> * Nix <nix@esperi.org.uk> [2007-07-05 22:42]:
>> 
>> My only real grouch with cmake is that the authors have invented a
>> language with so bloody many capital letters in it. 
>
> The real problem I see with cmake is that you need to have cmake
> installed on the build system.

I don't see that as being very much more of a problem than having make
installed (except of course that make is defined by POSIX and cmake is
not). The real problem is that nearly all the cmake macros are shipped
with cmake itself, so version-dependent scripts are more common, and
instead of being hit with `you need at least this version of GNU make,
released in 1998' you're likely to get hit with `you need at least this
version of cmake, released three months ago' which is more likely to
annoy the poor users.

>                                While cmake itself isn't the problem,
> often, it also depends on the version of cmake that is installed. The
> good idea about auto* tools is the idea that you don't need to install
> any tools to build, just to develop. A POSIX shell and Perl should be
> installed everywhere ...

You don't need Perl to run configure scripts, either, and it's only
recently that it started requiring a POSIX shell rather than something
of the calibre of Solaris's /bin/sh.



(But I'm spamming this list so I'll shut up now.)

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On Friday 06 July 2007, Nix wrote:
> On 5 Jul 2007, Bernhard Walle stated:
> >                                While cmake itself isn't the problem,
> > often, it also depends on the version of cmake that is installed. The
> > good idea about auto* tools is the idea that you don't need to install
> > any tools to build, just to develop. A POSIX shell and Perl should be
> > installed everywhere ...
>
> You don't need Perl to run configure scripts, either, and it's only
> recently that it started requiring a POSIX shell rather than something
> of the calibre of Solaris's /bin/sh.

since when does autotools require a POSIX shell ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Nix]

On 6 Jul 2007, Mike Frysinger spake thusly:

> On Friday 06 July 2007, Nix wrote:
>> On 5 Jul 2007, Bernhard Walle stated:
>> >                                While cmake itself isn't the problem,
>> > often, it also depends on the version of cmake that is installed. The
>> > good idea about auto* tools is the idea that you don't need to install
>> > any tools to build, just to develop. A POSIX shell and Perl should be
>> > installed everywhere ...
>>
>> You don't need Perl to run configure scripts, either, and it's only
>> recently that it started requiring a POSIX shell rather than something
>> of the calibre of Solaris's /bin/sh.
>
> since when does autotools require a POSIX shell ?

autoconf 2.55's NEWS said:

,----
| - shell functions
| 
|   Shell functions will gradually be introduced, probably starting with
|   Autotest.  If you know machines which are in use that you suspect
|   *not* to support shell functions, please run the test suite of
|   Autoconf 2.55 on it, and report the results to
|   bug-autoconf@gnu.org.
`----

but actually I'm not sure if this was ever done. That's not actually `a
POSIX shell' I suppose, but it's also not going to work on prehistoric
shells like Solaris's 1980-vintage /bin/sh.

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[DervishD]

    Hi Nix :)

 * Nix <nix@esperi.org.uk> dixit:
> On 5 Jul 2007, DervishD spake thusly:
> >> Configuring the build of an autotools program is harder than nescensary;
> >> if it used a config file, you could easily save it somewhere while adding
> >> comments on how and why you did *that* choice, and you could possibly
> >> use a set of default configs which you'd just include.
> >
> >     Looks like CMake...
> 
> That's cool :) thanks to KDE using it everyone's autobuilders are having
> to adapt to cmake anyway, and it's not hard and you only have to do it
> once.

    I really like the spirit of CMake. Of course, it adds a dependency,
but IMHO is much safer to depend on CMake being installed (or Perl, for
that matter) than to depend on a shell. Every shell out there seems to
do things on its own, and apart from dash, which is more or less
standard, the rest of shells do actually violate the standard one way or
another (in fact, configure script include workarounds for at least Bash
and Zsh).

> My only real grouch with cmake is that the authors have invented a
> language with so bloody many capital letters in it. Looking at cmake
> macros makes my eyes bleed even more badly than looking at the mass of
> involuted nested brackets in configure.ac's, and that's a difficult
> thing to do. (It's less portable than autoconf-generated configure
> scripts but most of autoconf's portability tests are for long-dead
> systems anyway, and as you said util-linux of all projects doesn't give
> a damn. I don't really care if software isn't portable to an Interactive
> box --- EOLed in 1992 --- or a SunOS 4.0 or HP-UX 8 box.)
> 
> There's a good reason most text is lowercase. Even Lisp moved to
> lowercase a long time ago...

    Well, that's nothing that a good editor can't solve. You can
configure VIM to lowercase your CMakelist while you edit, and uppercase
it afterwards. And yes, I also thing that's a bad idea and eyes hurt
badly when reading uppercase. Maybe it's not too late to change it ;)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

On Friday 06 July 2007, DervishD wrote:
>     I really like the spirit of CMake. Of course, it adds a dependency,
> but IMHO is much safer to depend on CMake being installed (or Perl, for
> that matter) than to depend on a shell. Every shell out there seems to
> do things on its own, and apart from dash, which is more or less
> standard, the rest of shells do actually violate the standard one way or
> another (in fact, configure script include workarounds for at least Bash
> and Zsh).

careful, you tread into dangerous territory making silly statements like that.  
by "standard" you probably mean "POSIX standard" which dash too has had 
plenty of bugs in terms of implementing it properly (and still does).  as for 
the workarounds you allude to, autotools is designed to be portable 
everywhere which means including workarounds for random bugs in major 
releases of operating systems.  just because autotools lacks workarounds for 
bugs found in random versions of dash does not make dash magical.  there is 
also the fact that autotools works on systems that predate POSIX or lack 
shells which support POSIX.  and claiming that it's safer to depend on CMake 
than bash in this Linux world is just plain bogus.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[DervishD]

    Hi Mike :)

 * Mike Frysinger <vapier@gentoo.org> dixit:
> On Friday 06 July 2007, DervishD wrote:
> >     I really like the spirit of CMake. Of course, it adds a dependency,
> > but IMHO is much safer to depend on CMake being installed (or Perl, for
> > that matter) than to depend on a shell. Every shell out there seems to
> > do things on its own, and apart from dash, which is more or less
> > standard, the rest of shells do actually violate the standard one way or
> > another (in fact, configure script include workarounds for at least Bash
> > and Zsh).
> 
> careful, you tread into dangerous territory making silly statements like that.  
> by "standard" you probably mean "POSIX standard" which dash too has had 
> plenty of bugs in terms of implementing it properly (and still does).

    Probably, I haven't carried thoroughly tests, but up to date, it's
the most POSIX compliant shell I've found. Probably dash is crappy too,
regarding POSIX compliance, but that only reinforces my point: depending
on shells is less safe than depending on CMake.

> and claiming that it's safer to depend on CMake 
> than bash in this Linux world is just plain bogus.

    Probably. I didn't claim that, anyway. I said "shell" and not
"Bash". Depending on a C program is safer, IMHO, than depending on the
features of an unknown shell. And FWIW, /bin/sh can be *any* shell on
*any* system where autotools run.

    And yes, I have bash installed on my system because some people
insist in writing bash scripts while asking for "#!/bin/sh". That's
bogus.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Bodo Eggert]

On Thu, 5 Jul 2007, DervishD wrote:
>  * Bodo Eggert <7eggert@gmx.de> dixit:

> > Standardisation is good, but autotools (as they are used) usurally isn't.
> 
>     Usually, by picking other's project configure.in and tweak blindly.

If it were that easy to write a correct automake script, people would do 
that. Wouldn't they?

> > Configuring the build of an autotools program is harder than nescensary;
> > if it used a config file, you could easily save it somewhere while adding
> > comments on how and why you did *that* choice, and you could possibly
> > use a set of default configs which you'd just include.
> 
>     Looks like CMake...

Obviously something I should look at.
-- 
Top 100 things you don't want the sysadmin to say:
45. Was that YOUR directory?

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[DervishD]

    Hi Bodo :)

 * Bodo Eggert <7eggert@gmx.de> dixit:
> On Thu, 5 Jul 2007, DervishD wrote:
> >  * Bodo Eggert <7eggert@gmx.de> dixit:
> 
> > > Standardisation is good, but autotools (as they are used) usurally isn't.
> > 
> >     Usually, by picking other's project configure.in and tweak blindly.
> 
> If it were that easy to write a correct automake script, people would do 
> that. Wouldn't they?

    That's exactly what I meant! People don't write good autotools
scripts because it's difficult to learn autoconf and automake and it's
almost impossible to master. It's more or less easy to write an autoconf
script, but it's not so easy to make it right, powerful and to honor
every configure switch, etc...

> > > Configuring the build of an autotools program is harder than nescensary;
> > > if it used a config file, you could easily save it somewhere while adding
> > > comments on how and why you did *that* choice, and you could possibly
> > > use a set of default configs which you'd just include.
> > 
> >     Looks like CMake...
> 
> Obviously something I should look at.

    Me too. I've learned a bit of CMake because I have my own building
system ("configure" compatible from the point of view of the packager),
but instead of adding new features I think I'm going to switch to CMake
fully.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Nix]

On 5 Jul 2007, Bodo Eggert outgrape:
> I'm really really happy if I read 'edit Makefile.conf and run make...'.

autobuild scripts find it a hell of a lot more annoying to edit a different
makefile for every project than to run one unchanging config.site...

It's hardly a killer, but it would be a step backwards IMO :( by all
means switch to a nicer build system: cmake, perhaps? but ditching
standardized build systems entirely is not so good.

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]

On Thursday 05 July 2007, Bodo Eggert wrote:
> Nix <nix@esperi.org.uk> wrote:
> > On 4 Jul 2007, DervishD stated:
> >>     Anyway, if you don't like mobs or you just don't want to try it,
> >> that's fine, but please don't use autotools, it doesn't make much sense
> >> for a linux only project, since you will be using only the "directory
> >> choosing" part of autotools. Maybe a hand made script will help (and I
> >
> > Oh, yeah, great, another hand-rolled build system. That's *juwt* what
> > those of us who have autotools working well (with config.site's that
> > do all we need and then some) are looking forward to.
> >
> > There are advantages to standardization, you know. A *lot* of
> > autobuilders know how to make autoconf-generated configure scripts jump
> > through hoops. I was downright *happy* when util-linux was
> > autoconfiscated: I could ditch the code to handle automatic
> > configuration of yet another one-package hand-rolled build system.
>
> Standardisation is good, but autotools (as they are used) usurally isn't.

i dont see how blaming autotools for other people's misuse is relevant ... 
this same exact claim could be made for just about any other build system, 
simply apply 's/autotools/$some_build_system_you_wish_to_complain/'.

> It tests for the availability of a fortran compiler for a C-only project

a libtool bug that has been fixed upstream and is trivial to work around ... 
you could also point out that libtool will also search for a C++ compiler in 
a C-only project.  the libtool stuff can probably be easily cleaned out from 
util-linux completely thus negating this whole topic.

> checks the width of integers on i386 for projects not caring about that and
> fails to find installed libraries without telling how it was supposed to
> find them or how to make it find that library.

no idea what this rant is about.

> Configuring the build of an autotools program is harder than nescensary;
> if it used a config file, you could easily save it somewhere while adding
> comments on how and why you did *that* choice, and you could possibly
> use a set of default configs which you'd just include.

history shows this is a pita to maintain.  every package has its own build 
system and configuration file which means you have to go through the 
documentation and figure out the magic incantation to get the thing to build 
up the way you need.

> The Makefiles generated by autotools is a huge mess, if autotools got it
> wrong (again!), fixing them requires editing a lot of files.

this looks like a no brainer to me: dont edit generated files
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Nix]

On 5 Jul 2007, Mike Frysinger outgrape:
> On Thursday 05 July 2007, Bodo Eggert wrote:
>> The Makefiles generated by autotools is a huge mess, if autotools got it
>> wrong (again!), fixing them requires editing a lot of files.
>
> this looks like a no brainer to me: dont edit generated files

There is a worthwhile point here: if your input to the makefile
generator is buggy and make errors out, you'll have to look at the
generated code in order to relate the make error to the original.

(It's not that hard with automake, admittedly, but make should
really have a #line analogue to help. It could be much worse, as
anyone who ever tried to use Knuth's old WEAVE tool would know.
At least automake doesn't intentionally obfuscate the makefiles
it emits...)

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

On Thursday 05 July 2007, Nix wrote:
> On 5 Jul 2007, Mike Frysinger outgrape:
> > On Thursday 05 July 2007, Bodo Eggert wrote:
> >> The Makefiles generated by autotools is a huge mess, if autotools got it
> >> wrong (again!), fixing them requires editing a lot of files.
> >
> > this looks like a no brainer to me: dont edit generated files
>
> There is a worthwhile point here: if your input to the makefile
> generator is buggy and make errors out, you'll have to look at the
> generated code in order to relate the make error to the original.

granted, this can be a pain (ive spent an annoying amount of time tracking 
down unbalanced quotes/parens/etc... by trying to correlate configure.ac with 
configure), but i dont feel like this is a autotool-specific issue as it can 
come up with other auto-build-generators as well.  heck, a minor typo in a 
hand written makefile can sometimes be a time sink and hard to trace back 
(just look at linux kernel makefiles).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Bryan Henderson]

>i dont see how blaming autotools for other people's misuse is relevant

Here's how other people's misuse of the tool can be relevant to the choice 
of the tool: some tools are easier to use right than others.  Probably the 
easiest thing to use right is the system you designed and built yourself. 
I've considered distributing code with an Autotools-based build system 
before and determined quickly that I am not up to that challenge.  (The 
bigger part of the challenge isn't writing the original input files; it's 
debugging when a user says his build doesn't work).  But as far as I know, 
my hand-rolled build system is used correctly by me.

>> checks the width of integers on i386 for projects not caring about that 
and
>> fails to find installed libraries without telling how it was supposed 
to
>> find them or how to make it find that library.
>
>no idea what this rant is about.

The second part sounds like my number 1 complaint as a user of 
Autotools-based packages: 'configure' often can't find my libraries.  I 
know exactly where they are, and even what compiler and linker options are 
needed to use them, but it often takes a half hour of tracing 'configure' 
or generated make files to figure out how to force the build to understand 
the same thing.  And that's with lots of experience.  The first five times 
it was much more frustrating.

>> Configuring the build of an autotools program is harder than 
nescensary;
>> if it used a config file, you could easily save it somewhere while 
adding
>> comments on how and why you did *that* choice, and you could possibly
>> use a set of default configs which you'd just include.
>
>history shows this is a pita to maintain.  every package has its own 
build 
>system and configuration file ...

It's my understanding that autotools _does_ provide that ability (as 
stated, though I think "config file" may have been meant here as 
"config.make").  The config file is a shell script that contains a 
'configure' command with a pile of options on it, and as many comments as 
you want, to tailor the build to your requirements.

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

On Thursday 05 July 2007, Bryan Henderson wrote:
> >i dont see how blaming autotools for other people's misuse is relevant
>
> Here's how other people's misuse of the tool can be relevant to the choice
> of the tool: some tools are easier to use right than others.  Probably the
> easiest thing to use right is the system you designed and built yourself.
> I've considered distributing code with an Autotools-based build system
> before and determined quickly that I am not up to that challenge.  (The
> bigger part of the challenge isn't writing the original input files; it's
> debugging when a user says his build doesn't work).  But as far as I know,
> my hand-rolled build system is used correctly by me.

which brings us back to the package maintainer maintains the autotool source 
files, not joe blow user.  if there's trouble with the build system, then the 
maintainers (who are knowledgeable in autotools) are in a pretty easy 
position to fix/address it.  as you've stated, hand rolled build systems work 
great for the guy rolling it, but beyond that all bets are off.  util-linux 
had a hand rolled build system that fell apart in many places.  the 
maintainers of util-linux have well versed autotool people at their disposal, 
so i really dont see this as being worrisome.

> > > checks the width of integers on i386 for projects not caring about that
> > > and fails to find installed libraries without telling how it was
> > > supposed to find them or how to make it find that library.
> >
> > no idea what this rant is about.
>
> The second part sounds like my number 1 complaint as a user of
> Autotools-based packages: 'configure' often can't find my libraries.  I
> know exactly where they are, and even what compiler and linker options are
> needed to use them, but it often takes a half hour of tracing 'configure'
> or generated make files to figure out how to force the build to understand
> the same thing.  And that's with lots of experience.  The first five times
> it was much more frustrating.

the large majority of time, i find this to be trivial: read config.log.  but 
this comes with familiarity with the tool and autotools is sitting by far the 
best right now.  if you're having trouble with the package in question, just 
ask on the mailing list and post your config.log; i'm sure you'd get someone 
to readily point out the answer.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

[Bryan Henderson]

>the 
>maintainers of util-linux have well versed autotool people at their 
disposal, 
>so i really dont see this as being worrisome.

As long as that is true, I agree that the fact that so many autotool 
packages don't work well is irrelevant.

However, I think the difficulty of using autotools (I mean using by 
packagers), as evidenced by all the people who get it wrong, justifies 
people being skeptical that util-linux really has that expertise 
available.  Also, many open source projects are developed by a large 
diverse group of people, so even if there exist people who can do the 
autotools right, it doesn't mean they'll be done right.

One reason I try to minimize the number of tools/skills used in 
maintaining packages I distribute is to enable a larger group of people to 
help me maintain them.