SEO

the same version ebuild,
> emerge -p cyrus-sasl

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild R ] dev-libs/cyrus-sasl-2.1.14
> emerge -p cyrus-sasl

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild R ] dev-libs/cyrus-sasl-2.1.14

1 compiled few months ago [OLD], and the other this month [NEW]
[OLD] does create /var/lib/sasl2 and:
[OLD]#cat /etc/conf.d/saslauthd
# Copyright 1999-2002 Gentoo Technologies, Inc. # Distributed under the
terms of the GNU General Public License, v2 or later # $Header:
/home/cvsroot/gentoo-x86/dev-libs/cyrus-sasl/files/saslauthd.confd-2.1,v
1.1 2003/06/22 17:28:04 raker Exp $

# Config file for /etc/init.d/saslauthd

# Authentications mechanism (for list see saslauthd -v) # Examples:
getpwent pam rimap shadow ldap SASL_AUTHMECH=pam

# Put other startup options here. Many options have changed recently. #
Use -O to do things previously broken out into separate flags.
SASL_DAEMON_OPTS=""

# Tack the above options together
[ -n ${SASL_AUTHMECH} ] && \
SASLAUTHD_OPTS="-a ${SASL_AUTHMECH}"
[ -n ${SASL_DAEMON_OPTS} ] && \
SASLAUTHD_OPTS="${SASLAUTHD_OPTS} ${SASL_DAEMON_OPTS}"

[NEW]Pretends to create /var/lib/sasl2 and does not work i.e.
> /etc/init.d/saslauthd start
* Starting saslauthd...
/usr/sbin/saslauthd: invalid option -- H usage: saslauthd [options]

option information:
-a <authmech> Selects the authentication mechanism to use. -c
Enable credential caching. -d Debugging (don't detach from
tty, implies -V) -O <option> Optional argument to pass to the
authentication
mechanism.
-l Disable accept() locking. Increases performance, but
may not be compatible with some operating systems.
-m <path> Alternate path for the saslauthd working directory,
must be absolute.
-n <procs> Number of worker processes to create. -s <kilobytes> Size
of the credential cache (in kilobytes) -t <seconds> Timeout for items
in the credential cache (in seconds) -v Display version
information and available mechs -V Enable verbose logging
authentication mechanisms and exit.
-h Dispaly this message.

saslauthd 2.1.14
authentication mechanisms: getpwent pam rimap shadow [!!]
[NEW]#cat/etc/conf.d/saslauthd
# Copyright 1999-2002 Gentoo Technologies, Inc. # Distributed under the
terms of the GNU General Public License, v2 or later # $Header:
/home/cvsroot/gentoo-x86/dev-libs/cyrus-sasl/files/saslauthd.conf,v 1.1
2004/01/14 19:42:47 max Exp $

# Config file for /etc/init.d/saslauthd

# Authentications mechanism (for list see saslauthd -v) SASL_AUTHMECH=pam

# Hostname for remote IMAP server (if rimap auth mech is used)
SASL_RIMAP_HOSTNAME=""

# Honour time-of-day login restrictions (if shadow auth mech is used) #
Make this ="" to turn it off. Putting =no will turn it on!
SASL_TIME_OF_DAY_LOGIN_RESTRICTIONS=yes


# Tack the above options together
[ -n ${SASL_AUTHMECH} ] && \
SASLAUTHD_OPTS="-a ${SASL_AUTHMECH}"
[ -n ${SASL_RIMAP_HOSTNAME} ] && \
SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -H ${SASL_RIMAP_HOSTNAME}"
[ -n ${SASL_TIME_OF_DAY_LOGIN_RESTRICTIONS} ] && \
SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -T"
###
After copying /etc/conf.d/saslauthd from [OLD] to [NEW] it starts working!
What is going on? how is it possible that gentoo developers change ebuilds
without renumbering versions? something VERY WRONG is going on in Gentoo

PiotrAF wrote:

> After copying /etc/conf.d/saslauthd from [OLD] to [NEW] it starts working!

I didn't fight my way through everything you posted, but reading the
Changelog [1] could give you some hints why there are differences.

> What is going on? how is it possible that gentoo developers change ebuilds
> without renumbering versions?

Version bumping (e.g. r7->r8) is only done when there are non-trivial
changes or changes that affect _many_ people. See the other side: If every
little change in, say, the xfree-ebuild would result in a version bump,
many Gentoo users would spend much time re-compiling xfree for no reason.

> something VERY WRONG is going on in Gentoo
>

No :-)

[1] http://www.gentoo.org/cgi-bin/ \
viewcvs.cgi/*checkout*/dev-libs/cyrus-sasl/ChangeLog

On Tue, 24 Feb 2004 15:22:33 +0100, Dennis Nienhüser wrote:

>
> Version bumping (e.g. r7->r8) is only done when there are non-trivial
> changes or changes that affect _many_ people. See the other side: If every
> little change in, say, the xfree-ebuild would result in a version bump,
> many Gentoo users would spend much time re-compiling xfree for no reason.

I disagree with that especially when the trivial change is so trivial it
makes it impossible to use the software - and IMHO it is unaccaptable in
stable version. You may do such things in ~x86

>
>> something VERY WRONG is going on in Gentoo
>>
>
> No :-)

Yes, I must say that when I started in april last year , gentoo x86 was
much more bugless and trustworthy and IMHO this will not gain it more
satisfied users - that's the main reason why e.g. Mandrake lost so many
users - the race to untested new versions of soft included in stable
version.

>
> [1] http://www.gentoo.org/cgi-bin/ \
> viewcvs.cgi/*checkout*/dev-libs/cyrus-sasl/ChangeLog

I will look at this

On Tue, 24 Feb 2004 16:40:27 +0100, PiotrAF wrote:

>
> I disagree with that especially when the trivial change is so trivial it
> makes it impossible to use the software - and IMHO it is unaccaptable in
> stable version. You may do such things in ~x86
>
>>
>>> something VERY WRONG is going on in Gentoo
>>>

In my case, it made me switch the server to FreeBSD, and leave Gentoo only
for desktop use. Still, it's unbelievable software policy IMHO.