RE: Installation of Recommends by default on October 1st

[Jared Kells]

There is a big difference between Recommends and Depends. Depends are
required for a piece of software to work. Recommends should be installed
with a piece of software the majority of the time, but the software can
still work without them, although some features may be disabled. Suggests
are just that suggestions.

I think the new policy is a great idea. As a desktop user and I think in the
majority of use cases, when someone installs something with apt-get they
expect A fully functional piece of software. I know a number of times I have
installed some software that I am not entirely familiar with and find many
standard features missing because I didn't manually check the Recommends.
The software still "works" but often only just!

I also think its good policy for people like yourself creating embedded
systems. With recommends NOT a default maintainers feel pressured to add
additional depends so their software will be "fully" functional with a
simple apt-get install. Now they can move these packages from depends into
recommends. A default install is now fully functional and the special use
case of an embedded system (which would obviously disable the option) will
get an even smaller package.

As it currently stands recommends and suggests blend together. I think
installing recommends by default sharply separates all three.

Regards
Jared


 



> Policy does not mandate that ALL Recommends: are to be installed. The new 
> default makes Recommends: disappear completely - there would be no
difference 
> between Depends: and Recommends: just like there is a perception of no
real
> difference between Recommends: and Suggests: at the moment. That makes
things
> HARDER for people like me who do not want Recommends: because maintainers
> will lose any reason to put things in Recommends: and will end up putting
> everything in Depends: just as many current Recommends: are actually just
> Suggests:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: release update: Release goals, testing transition, arch requalification

[Lionel Elie Mamane]

On Sun, Jul 29, 2007 at 07:58:47PM +0200, Luk Claes wrote:

> Ok, now to the approved release goals:
> - full IPv6 support

What does that mean precisely? Drop all packages that don't support
IPv6? IPv6 shall be enabled if supported not too buggily? Something in
between? (I'm quite certain you don't mean drop all packages that
don't support IPv6.)

-- 
Lionel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Steve Langasek]

On Thu, Aug 02, 2007 at 06:54:49AM +0200, Mike Hommey wrote:
> On Wed, Aug 01, 2007 at 02:22:38PM -0700, Steve Langasek <[EMAIL PROTECTED]> 
> wrote:
> > On Wed, Aug 01, 2007 at 10:38:41PM +0200, Adeodato Simó wrote:
> > > > > >   Then he'll be able to move /bin/sh symlink on bash if he wants to.

> > > > > Right.  Hence that's the point for the user to change /bin/sh.  :)

> > > > > I have no problem with dash being the default.  I was just defending 
> > > > > our
> > > > > committment to let the user change /bin/sh if they want to.

> > > >   Yes, I never thought we were about to remove the fact that /bin/sh was
> > > > a symlink that the user could be able to change whenever he wants. I
> > > > don't think debconf questions or alike are wise FWIW though.

> > > So how will be that achieved in a way that's persistant across upgrades,
> > > if both debconf and alternatives are being rejected?

> > diversions.

> diversions are far from being atomic.

True, but it is persistent across upgrades and doesn't require any
particular support from the package.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Mike Hommey]

On Wed, Aug 01, 2007 at 11:30:33PM +0100, Neil Williams <[EMAIL PROTECTED]> 
wrote:
> Policy does not mandate that ALL Recommends: are to be installed. The
> new default makes Recommends: disappear completely - there would be no
> difference between Depends: and Recommends: just like there is a
> perception of no real difference between Recommends: and Suggests: at
> the moment.

There is actually quite a big difference between the "new" Recommends
and Depends: you can uninstall Recommends without uninstalling reverse
dependencies.

By the way, we could even add something to deborphan or similar tools to
propose to uninstall Recommends that are not used by the user, based on
data from popcon, for example.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Mike Hommey]

On Wed, Aug 01, 2007 at 02:22:38PM -0700, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> On Wed, Aug 01, 2007 at 10:38:41PM +0200, Adeodato Simó wrote:
> > > > >   Then he'll be able to move /bin/sh symlink on bash if he wants to.
> 
> > > > Right.  Hence that's the point for the user to change /bin/sh.  :)
> 
> > > > I have no problem with dash being the default.  I was just defending our
> > > > committment to let the user change /bin/sh if they want to.
> 
> > >   Yes, I never thought we were about to remove the fact that /bin/sh was
> > > a symlink that the user could be able to change whenever he wants. I
> > > don't think debconf questions or alike are wise FWIW though.
> 
> > So how will be that achieved in a way that's persistant across upgrades,
> > if both debconf and alternatives are being rejected?
> 
> diversions.

diversions are far from being atomic.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Oleg Verych]

* Pierre Habouzit:
>
>> Well, bash is essential, so you have to have that one installed or else y=
> ou
>> have to scan all your packages for uses of bash and convert them.
>
>   Let's make it a release goal !

In my TODO list. The quilt is one of main goals; not only bash->sh but
also awk->no awk. At least i will try.

Now, after i've done my aggressive janitor, it's time to get rid of some
bloat inside scripts also. There's an example[0] of pure size reduction
in tzselect to make it less than 4096 bytes.

[0] ftp://flower.upol.cz/geloiwa/src/usr/local/etc/geloiwa/iwant



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

perl, shell, size of installed packages (Re: Cleanup before install)

[Oleg Verych]

* 31-07-2007, Marc Haber:

> On Tue, 31 Jul 2007 19:09:10 + (UTC), Oleg Verych
>
>>- adduser is 48k of "unreadable perl mess"
>
> As former maintainer of adduser, I take offense here. Adduser has
> improved a lot in readability in the last three years.

This is a funny quote i've get from the `bts' command sources.


* Debian Development List.

Seriously, after reading all that shell and apt threads, i wonder if all
that size thing really matters? Install 4G of Vista++ and be stupidly
happy.

I thought, it's a good thing to have size concerns in the first place.
It's even matter of taste, not only technical problems with
disks/filesystems speed.

In order.

* adduser is the 48k wrapper around passwd (hope you've read that earlier);
  man page says, low level `user*' command should not be used. WTF? To
  remove or add ordinary user _once_ in first installation, i must carry
  this crap all along? Sorry, guys. I'd better try to fix install scripts
  of cron, mutt, exim-daemon-light, openssh-*. I'm sure nothing extra
  ordinary happens there.

* same song in bash's man page: no clear line between its features and
  Bourne Shell requirements. The long standing bug -- size and speed
  has kind place in that man page. And after all that, everybody write
  `#!/bin/sh' and hope it's a good shell scripting, while it turns to
  a very bash specific script, that will run 2-3 times slower.

* apt-get's man page states, that apt-get is the command line tool and
  is a "back-end". If quoted word there is humor, then remove it or
  leave default behavior as is.

Very disappointing things, that can really be offensive. Because you
think it's good an optimized process of being better and better, but
nope. There are agendas (tiding to GNU bash), laziness (try lightweight
useradd/userdel in once-run branch in install scripts first) and other
non technical problems.

I don't know (yet) all policies on how to package, but one thing i see:

there's no way to supply options to install scripts, so admin/user can
just blindly run installation/upgrade.

Debconf is another sort of design/size issues, i have.
--
-o--=O`C
 #oo'L O
<___=E M


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Anthony Towns]

On Wed, Aug 01, 2007 at 06:00:21PM +0200, Pierre Habouzit wrote:
> On Wed, Aug 01, 2007 at 12:53:03PM -0300, Henrique de Moraes Holschuh wrote:
> > OTOH, specifically using something else than /bin/sh for a fast
> > POSIX-with-the-extensions-Debian-mandates shell (i.e. forget posh, but dash
> > is good) does NOT need /bin/sh to point to it, so it can't trip on such
> > issues caused by external factors outside of Debian's control.
>   Afaict ubuntu did the change, and the sky didn't fell apart.

It did cause a bunch of problems for Ubuntu users, though:

https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463

Cheers,
aj



signature.asc
Description: Digital signature

AlphaPC, 600MHz, 128MB Donation

[Eric Dorland]

Hello alpha lovers,

I have a AlphaPC collecting dust in my apartment that should probably
go to someone who might actually put it to a good use. I'm in the New
York area so being nearby would make things easier but I'm willing to
work out shipping it somewhere if you're very keen.

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6



signature.asc
Description: Digital signature

Bug#435619: RFP: kopete/pidgin -- [SHORT DESCRIPTION]

[craigevil]

Package: pidgin
Severity: crashing
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

Package name: kopete/pidgin
Version:
Upstream Author: [NAME ]
URL: [http://example.com]
License: [GPL, LGPL, BSD, MIT/X, etc.]
Description: [DESCRIPTION]

After todays update of pidgin in unstable it crashes with a simple 
segfault. So I tried running kopete, then attempted to open pidgin, 
kopete then crashed.


Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1208514880 (LWP 5857)]
[KCrash handler]
#5  0xb7af311f in Client::streamReadyRead (this=0x835caa0)
   at 
/tmp/buildd/kdenetwork-3.5.7/./kopete/protocols/yahoo/libkyahoo/client.cpp:238

#6  0xb7af7642 in Client::qt_invoke (this=0x835caa0, _id=8, _o=0xbfd0c6bc)
   at ./client.moc:898
#7  0x42d68d23 in QObject::activate_signal (this=0x845ccd0, 
clist=0x83a5818,

   o=0xbfd0c6bc) at kernel/qobject.cpp:2356
#8  0x42d697c8 in QObject::activate_signal (this=0x845ccd0, signal=10)
   at kernel/qobject.cpp:2325
#9  0xb7afd0fc in ClientStream::readyRead (this=0x845ccd0)
   at ./yahooclientstream.moc:155
#10 0xb7afd12d in ClientStream::doReadyRead (this=0x845ccd0)
   at 
/tmp/buildd/kdenetwork-3.5.7/./kopete/protocols/yahoo/libkyahoo/yahooclientstream.cpp:393

#11 0xb7afd18d in ClientStream::cp_incomingData (this=0x845ccd0)
   at 
/tmp/buildd/kdenetwork-3.5.7/./kopete/protocols/yahoo/libkyahoo/yahooclientstream.cpp:316

#12 0xb7afdced in ClientStream::qt_invoke (this=0x845ccd0, _id=6,
   _o=0xbfd0c7dc) at ./yahooclientstream.moc:165
#13 0x42d68d23 in QObject::activate_signal (this=0x8594624, 
clist=0x85bbbf8,

   o=0xbfd0c7dc) at kernel/qobject.cpp:2356
#14 0x42d697c8 in QObject::activate_signal (this=0x8594624, signal=3)
   at kernel/qobject.cpp:2325
#15 0xb7b02d6c in CoreProtocol::incomingData (this=0x8594624)
   at ./coreprotocol.moc:110
#16 0xb7b03175 in CoreProtocol::wireToTransfer (this=0x8594624,
   [EMAIL PROTECTED])
   at 
/tmp/buildd/kdenetwork-3.5.7/./kopete/protocols/yahoo/libkyahoo/coreprotocol.cpp:180

#17 0xb7b032ef in CoreProtocol::addIncomingData (this=0x8594624,
   [EMAIL PROTECTED])
   at 
/tmp/buildd/kdenetwork-3.5.7/./kopete/protocols/yahoo/libkyahoo/coreprotocol.cpp:67

#18 0xb7afda56 in ClientStream::bs_readyRead (this=0x845ccd0)
   at 
/tmp/buildd/kdenetwork-3.5.7/./kopete/protocols/yahoo/libkyahoo/yahooclientstream.cpp:378

#19 0xb7afdd42 in ClientStream::qt_invoke (this=0x845ccd0, _id=10,
   _o=0xbfd0c9ec) at ./yahooclientstream.moc:169
#20 0x42d68d23 in QObject::activate_signal (this=0x8218428, 
clist=0x84cbba8,

   o=0xbfd0c9ec) at kernel/qobject.cpp:2356
#21 0x42d697c8 in QObject::activate_signal (this=0x8218428, signal=4)
   at kernel/qobject.cpp:2325
#22 0xb7afc38c in ByteStream::readyRead (this=0x8218428)
   at ./bytestream.moc:108
#23 0xb7afbdec in KNetworkByteStream::slotReadyRead (this=0x8218428)
   at 
/tmp/buildd/kdenetwork-3.5.7/./kopete/protocols/yahoo/libkyahoo/yahoobytestream.cpp:122

#24 0xb7afbec2 in KNetworkByteStream::qt_invoke (this=0x8218428, _id=4,
   _o=0xbfd0cb1c) at ./yahoobytestream.moc:108
#25 0x42d68d23 in QObject::activate_signal (this=0x84a6f80, 
clist=0x857c378,

   o=0xbfd0cb1c) at kernel/qobject.cpp:2356
#26 0x42d697c8 in QObject::activate_signal (this=0x84a6f80, signal=9)
   at kernel/qobject.cpp:2325
#27 0x4343e0ec in KNetwork::KClientSocketBase::readyRead (this=0x84a6f80)
   at ./kclientsocketbase.moc:192
#28 0x4343e126 in KNetwork::KClientSocketBase::slotReadActivity (this=0x6)
   at 
/tmp/buildd/kdelibs-3.5.7.dfsg.1/./kdecore/network/kclientsocketbase.cpp:416
#29 0x43446308 in KNetwork::KBufferedSocket::slotReadActivity 
(this=0x84a6f80)
   at 
/tmp/buildd/kdelibs-3.5.7.dfsg.1/./kdecore/network/kbufferedsocket.cpp:354

#30 0x434502fb in KNetwork::KBufferedSocket::qt_invoke (this=0x84a6f80,
   _id=8, _o=0xbfd0cc58) at ./kbufferedsocket.moc:97
#31 0x42d68d23 in QObject::activate_signal (this=0x8599dc0, 
clist=0x8619de0,

   o=0xbfd0cc58) at kernel/qobject.cpp:2356
#32 0x42d6963a in QObject::activate_signal (this=0x8599dc0, signal=2,
   param=14) at kernel/qobject.cpp:2449
#33 0x430f60f7 in QSocketNotifier::activated (this=0x8599dc0, t0=14)
   at .moc/debug-shared-mt/moc_qsocketnotifier.cpp:85
#34 0x42d8b9b6 in QSocketNotifier::event (this=0x8599dc0, e=0xbfd0cfb0)
   at kernel/qsocketnotifier.cpp:258
#35 0x42d004e0 in QApplication::internalNotify (this=0xbfd0d23c,
   receiver=0x8599dc0, e=0xbfd0cfb0) at kernel/qapplication.cpp:2635
#36 0x42d0230f in QApplication::notify (this=0xbfd0d23c, 
receiver=0x8599dc0,

   e=0xbfd0cfb0) at kernel/qapplication.cpp:2358
#37 0x433f42c2 in KApplication::notify (this=0xbfd0d23c, 
receiver=0x8599dc0,

   event=0xbfd0cfb0)
   at /tmp/buildd/kdelibs-3.5.7.dfsg.1/./kdecore/kapplication.cpp:550
#38 0x42c93595 in QApplication::sendEvent (receiver=0x8599dc0,
   event=0xbfd0cfb0) at ../include/qapplication.h:520
#39 0x42cf2819 in QEventLoop::activateSocketNotifiers (this=0x8231b20)
   

Re: Installation of Recommends by default on October 1st

[Joey Hess]

Pierre Habouzit wrote:
>   I mean, recommends means that having the recommends installed may e.g.
> enable some additionnal features in your package.

No, recommends means that:

  This declares a strong, but not absolute, dependency.

You're thinking of suggests:

  This is used to declare that one package may be more useful with
  one or more others.

> See openoffice.org, I think it recommends java or many things like that.
> If I don't want to install java and the hundreds of megabytes it come
> with, how am I supposed to do ?
> 
> apt-cache show openoffice.org-writer |grep Recom
> Recommends: openoffice.org-filter-binfilter, gij | java-gcj-compat | j2re1.4 
> | java2-runtime, openoffice.org-java-common (>> 2.2.0-4)

apt-get install openoffice.org gij- ?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Installation of Recommends by default on October 1st

[Joey Hess]

Neil Williams wrote:
> The problem is that with packages like gnome-devel and gnome-core-devel
> (re: anjuta) >50% will require SOME of the Recommended packages. As a
> long term anjuta user, I would estimate that <5% of all users need ALL
> Recommended packages.
> 
> What is the anjuta / gnome-devel maintainer meant to do in this
> situation? S/He isn't psychic, there is no way to know which Recommends
> are going to be a waste of space. That is up to the user, so let the
> user decide - on a per-package basis.

> Policy does not mandate that ALL Recommends: are to be installed. The
> new default makes Recommends: disappear completely - there would be no
> difference between Depends: and Recommends: just like there is a
> perception of no real difference between Recommends: and Suggests: at
> the moment.

Look at what happens when I install anjuta with the new default enabled:

[EMAIL PROTECTED]:~>sudo apt-get install --install-recommends anjuta
Password:
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following extra packages will be installed:
  anjuta-common autogen automake bluefish doc-gnome-hig exuberant-ctags
  glade-gnome gnome-common gnome-core-devel gnome-devel gtk-doc-tools
  gtranslator libatspi-dev libgail-gnome-dev libgail-gnome-module libgbf-1-0
  libgbf-1-common libgdl-gnome-1-0 libgtkhtml3.14-dev liboobs-1-dev libopts25
  libopts25-dev libpango1.0-0 libpango1.0-common libpango1.0-dev
  libsoup2.2-dev libvte-dev libvte9 libxslt1-dev libxtst-dev
  x11proto-record-dev
Suggested packages:
  libgtkmm2.0-dev libgnomemm2.0-dev devhelp-books glade-2 glade-gnome-2
  automake1.10-doc weblint-perl weblint at-spi-doc ttf-kochi-gothic
  ttf-kochi-mincho ttf-thryomanes ttf-baekmuk libsoup2.2-doc
Recommended packages:
  ctags
The following NEW packages will be installed:
  anjuta anjuta-common autogen automake bluefish doc-gnome-hig exuberant-ctags
  glade-gnome gnome-common gnome-core-devel gnome-devel gtk-doc-tools
  gtranslator libatspi-dev libgail-gnome-dev libgail-gnome-module libgbf-1-0
  libgbf-1-common libgdl-gnome-1-0 libgtkhtml3.14-dev liboobs-1-dev libopts25
  libopts25-dev libsoup2.2-dev libvte-dev libxslt1-dev libxtst-dev
  x11proto-record-dev
The following packages will be upgraded:
  libpango1.0-0 libpango1.0-common libpango1.0-dev libvte9
4 upgraded, 28 newly installed, 0 to remove and 92 not upgraded.
Need to get 13.3MB/14.8MB of archives.
After unpacking 42.8MB of additional disk space will be used.
Do you want to continue [Y/n]? 

Since apt lists Recommends in its own area, they are not indistinguishable
from Depends (or Suggests). Also, if I decide I don't want ctags, I can
hit "N" and run

[EMAIL PROTECTED]:~>sudo apt-get install --install-recommends anjuta ctags-

Need to get 13.2MB/14.7MB of archives.
After unpacking 42.6MB of additional disk space will be used.
Do you want to continue [Y/n]? 

Thereby saving that crucial .2 MB of disk space that all installers
of GNOME IDEs certianly care about. ;-)

> Recommends: because maintainers will lose any reason to put things in
> Recommends: and will end up putting everything in Depends: just as many
> current Recommends: are actually just Suggests:

> Overlap between Recommends: and Suggests: is FAR LESS of a problem
> than blurring the lines between Recommends: and Depends: as WILL
> happen when people get used to the new default and assume that
> everyone has all the Recommends: anyway.

Don't these two statements contradict each other?

> Has anyone even considered the extra bandwidth / code churn / mirror
> requirements of adding hundreds of unwanted packages to every
> new installation?

To reiterate, recommended packages will not be installed by by d-i until
all the recommends are sane. In d-i/tasksel we currently have to track
recommends and hardcode the sane ones on while ignoring the other ones,
which is tedious and failure prone.
 
-- 
see shy jo


signature.asc
Description: Digital signature

Re: Installation of Recommends by default on October 1st

[Joey Hess]

Neil Williams wrote:
> And a script to implement that in every box I have to install. Again
> and Again and Again and 
> 
> You almost forcing me into maintaining a fork of apt that restores the
> current behaviour from the very start.

Forking apt and putting a line in a config file seem two quite
dissimilar levels of work. YMMV I guess.

> No - because the default is already in place in aptitude which is WHY I
> don't use aptitude. If apt goes the same way, the default configuration
> of each offers no choice.
> 
> By the time I get a chance to switch that option off, the installation
> has added loads of JUNK that I do NOT want.

As was noted in the initial mail, d-i already disables installation of
recommends by default. debootstrap also does not install recommends by
default. So no matter how you're installing, I don't see why you'd get
any extra stuff added by the installation before the point where you can
put the line in the config file.

I'd like d-i to be able to install recommends in the future, but we
can't do that until all the packages d-i installs have sane recommends,
and we're not there yet (#388290). Turning recommends on by default in
apt and exposing maintainers to all the bad recommends out there seems
like a good way to get them fixed.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: /bin/sh diversions

[Joey Hess]

Pierre Habouzit wrote:
>   Yes, I never thought we were about to remove the fact that /bin/sh was
> a symlink that the user could be able to change whenever he wants. I
> don't think debconf questions or alike are wise FWIW though.
> 
>   In fact what happens currently with bash/dash is fine, just with
> /bin/sh being dash instead of bash for new installations.

dash already uses debconf to manage the /bin/sh symlink. It has since
2002, so I don't know what your concern is with using debconf there.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Installation of Recommends by default on October 1st

[Bernd Zeimetz]

> The problem is that with packages like gnome-devel and gnome-core-devel
> (re: anjuta) >50% will require SOME of the Recommended packages. As a
> long term anjuta user, I would estimate that <5% of all users need ALL
> Recommended packages.

Then the packages should not be in Recommends - Suggests is a good place
for them. Especially with -dev packages I can't see a reason to
'recommend' another package - either you need foo-dev to be able to use
bar-dev, or not. Developers usually know which libraries they want to use.

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Felipe Sateler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Neil Williams wrote:


> Why would apt now force someone in my situation to add all these
> *unnecessary* packages

Because, if recommends were used properly, they wouldn't be unnecessary.
Also, nobody is forcing you to install anything. Recommends can be
removed/not installed. Automatically installing them goes with the spirit
of what it means: software you would normally install alongside the one you
are installing. If you are not installing it is because you know what you
are doing.


- -- 

  Felipe Sateler
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGsRRC19K8LkCXFHcRAr6yAJ9rWxn45GviBVvn3yPdWlv8qs5PwwCfd0g+
9XqlWOBaZZFuzLQ0D98ME4E=
=CIq7
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Sam Morris]

On Wed, 01 Aug 2007 23:49:27 +0200, Julien BLACHE wrote:

> I'd really like it if we could keep apt-get as an advanced user tool;
> aptitude can be used in all the other cases.

The problem is that apt-get is *not* an advanced user tool. End users use 
it because they see it referenced in all our documentation, all the 
documentation they find elsewhere on the web and in our mailing list 
archives, all the conversations they have on IRC while trying to find 
help, etc...

-- 
Sam Morris
http://robots.org.uk/
 
PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Steve Langasek]

On Wed, Aug 01, 2007 at 02:59:13PM +, Thorsten Glaser wrote:
> Pierre Habouzit dixit:

> >I don't see a valid reason for the
> >user to chose what lies behind /bin/sh.

> Debian policy allows it.

Debian Policy requires scripts that invoke /bin/sh to limit themselves to
the POSIX subset of functionality.  It does not require maintainers of shell
implementations to go through additional rigamarole to support switching
/bin/sh as part of the package itself.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Neil Williams]

On Wed, 1 Aug 2007 22:40:44 +0200
Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> On Wed, Aug 01, 2007 at 07:14:14PM +0100, Neil Williams wrote:
> > undone whenever I install a new box? I'll certainly need something like
> > that for the cross-built apt for Emdebian
> > - embedded devices will not cope with this change.
> 
> You can easily drop a file in /etc/apt/apt.conf.d in some base emdebian
> package, methinks. That shouldn't be too hard, no?

I just wish it wasn't necessary.
:-(

There are some real lunatic settings for Recommends based on my initial
tests on this box - gnome-applets will default to installing all the
gnome cil libraries and mono-runtime. #435601

gnome-games needing the truly enormous and high-end theoretical
mathematics package atlas3? #435602

The OOo ones already mentioned.

xserver-xorg soon to be requiring the installation of ALL
xserver-xorg-video-foo drivers - I've only got one graphics card!
(#435604)

There are also some (anjuta && gnome-devel and gnome-core-devel) which
would appear reasonable and yet I have not found any use for a long
list of packages brought in by that chain:

Installing exuberant-ctags as dep of anjuta
Installing gnome-devel as dep of anjuta
Installing gnome-core-devel as dep of gnome-devel
Installing libatspi-dev as dep of gnome-core-devel
Installing libatspi1.0-0 as dep of libatspi-dev
Installing libxtst-dev as dep of libatspi-dev
Installing x11proto-record-dev as dep of libxtst-dev
Installing libeel2-dev as dep of gnome-core-devel
Installing libgstreamer-plugins-base0.10-dev as dep of gnome-core-devel
Installing libgtksourceview-dev as dep of gnome-core-devel
Installing libgail-gnome-dev as dep of gnome-core-devel
Installing libgail-gnome-module as dep of libgail-gnome-dev
Installing libgnomekbd-dev as dep of gnome-core-devel
Installing libxklavier11-dev as dep of libgnomekbd-dev
Installing libgnomekbdui-dev as dep of gnome-core-devel
Installing libnautilus-extension-dev as dep of gnome-core-devel
Installing liboobs-1-dev as dep of gnome-core-devel
Installing libwnck-dev as dep of gnome-core-devel
Installing libxres-dev as dep of libwnck-dev
Installing x11proto-resource-dev as dep of libxres-dev
Installing libvte-dev as dep of gnome-core-devel
Installing bluefish as dep of gnome-devel

I just don't see the need. I mean I use anjuta for almost a dozen
upstream projects, I have lots of -dev packages installed, lots of -doc
packages installed. I have all that I think I need and none of the
Recommends in that list will add the few features that I still need in
anjuta (the subversion plugin and a working Help menu option) {bugs
#368230 and #368231}. 

That is what I understood as the meaning of Recommends: "the maintainer
thinks you probably need these but you do not need them just to run the
program so it is up to you."

Why would apt now force someone in my situation to add all these
*unnecessary* packages

It's a bad idea, IMHO and that's all I can say.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpv00M3COzRO.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Neil Williams]

On Wed, 01 Aug 2007 22:52:46 +0200
Reinhard Tartler <[EMAIL PROTECTED]> wrote:

> > Recommends does NOT apply to everyone - that is Policy. 
> 
> : Recommends 
> :
> :   This declares a strong, but not absolute, dependency.
> :   The Recommends field should list packages that would be found 
> :   together with this one in all but unusual installations.

The problem is that with packages like gnome-devel and gnome-core-devel
(re: anjuta) >50% will require SOME of the Recommended packages. As a
long term anjuta user, I would estimate that <5% of all users need ALL
Recommended packages.

What is the anjuta / gnome-devel maintainer meant to do in this
situation? S/He isn't psychic, there is no way to know which Recommends
are going to be a waste of space. That is up to the user, so let the
user decide - on a per-package basis.

Recommends: is easy with small packages, it becomes more difficult when
each user does different things with the one package.

Are we supposed to have anjuta-gtk, anjuta-console, anjuta-glib,
anjuta-glade, anjuta-gnome, anjuta-custom . . . .  each with their own
Recommends: ?

> > What apt is now doing is undermining Policy by removing that CHOICE to
> > not use any recommended packages.
> 
> No. The apt team intends to finally implement what is mandated by Debian
> Policy for years.

Policy does not mandate that ALL Recommends: are to be installed. The
new default makes Recommends: disappear completely - there would be no
difference between Depends: and Recommends: just like there is a
perception of no real difference between Recommends: and Suggests: at
the moment. That makes things HARDER for people like me who do not want
Recommends: because maintainers will lose any reason to put things in
Recommends: and will end up putting everything in Depends: just as many
current Recommends: are actually just Suggests:

The blanket default that does not take the real meaning of Policy.

Proponents of the change need to rationalise just how much wasted disc
space is involved in accepting the installation of all Recommends: for
all packages at all times for all but the most pig-headed users. (i.e.
me).

Has anyone even considered the extra bandwidth / code churn / mirror
requirements of adding hundreds of unwanted packages to every
new installation?

A simple boolean default cannot enforce actual Policy. Set the default
to Recommends:On and Recommends =~ Depends. Set the default to
Recommends:Off and Recommends =~ Suggests (which is where we are now).

Personally, I think we are better off as-is. Overlap between Recommends:
and Suggests: is FAR LESS of a problem than blurring the lines between
Recommends: and Depends: as WILL happen when people get used to the new
default and assume that everyone has all the Recommends: anyway.

I fear that at the end of this whole sorry mess, Recommends will still
be broken, just broken in the opposite way to how it is broken now.

A boolean default cannot solve the problem.

Right problem. Wrong solution.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpx1XrC8zoRQ.pgp
Description: PGP signature

Re: /bin/sh diversions

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:
> On Wed, Aug 01, 2007 at 01:44:11PM -0700, Russ Allbery wrote:

>> Can we create the symlink in the postinst of base-files or something
>> else equally core, but only on initial installation or if the symlink
>> is missing?

> As long as the postinst of base-files doesn't have #!/bin/sh at the top,
> I guess? :-)

Right, it could use #!/bin/dash or #!/bin/bash as appropriate.  Hm, that
may generally be a problem for all essential packages, though, if the
symlink isn't guaranteed to be present early enough in a bootstrap.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Julien BLACHE]

Loïc Minier <[EMAIL PROTECTED]> wrote:

>> We have frontends like aptitude to automatically install recommends.
>
>  and it's the single frontend doing this: synaptic + apt-get are very
>  common and there was no reason to duplicate this logic in all
>  frontends.

Keeping the current apt default of NOT installing recommended packages
and having synaptic explicitely enable the automatic installation of
recommended packages could be a solution, too.

Though, doesn't synaptic pass the list of packages to install to apt ?
I guess synaptic can add the recommended packages to the list all by
itself, in this case.

I'd really like it if we could keep apt-get as an advanced user tool;
aptitude can be used in all the other cases.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Amir Tabatabaei]

On Wed, 2007-08-01 at 22:38 +0200, Pierre Habouzit wrote:
> On Wed, Aug 01, 2007 at 09:56:43PM +0200, Loïc Minier wrote:
> > On Wed, Aug 01, 2007, Marco d'Itri wrote:
> > > > We, the APT Development Team, will change apt to install recommended
> > > > packages by default on October 1st. This should give enough time to
> > > Why? What is the point?
> > 
> >  Fix Recommends!  These are nothing more than Suggests right now --
> >  except in aptitude.
> 
>   Well, even if they were used properly (and we agree they aren't, see
> the bug Joss filed on lighttpd e.g. ...), I'm not bought to the argument
> that _apt_ should install those by default.
> 
>   I mean, recommends means that having the recommends installed may e.g.
> enable some additionnal features in your package. But if the user don't
> need them, then what ? he will download loads of packages for nothing ?
> See openoffice.org, I think it recommends java or many things like that.
> If I don't want to install java and the hundreds of megabytes it come
> with, how am I supposed to do ?
> 
> apt-cache show openoffice.org-writer |grep Recom
> Recommends: openoffice.org-filter-binfilter, gij | java-gcj-compat | j2re1.4 
> | java2-runtime, openoffice.org-java-common (>> 2.2.0-4)
> 
>   And really, I think this recommends like is perfectly correct, as many
> features in OOo are enabled if you have java installed.

Sometimes you don't want recommends or depends [0] and sometimes they
are necessary [1].

I know it's stupid:
--
$ apt-get install --fix-policy --install-recommends
[...]
0 upgraded, 275 newly installed, 1 to remove and 0 not upgraded.
Need to get 311MB/311MB of archives.
After unpacking 839MB of additional disk space will be used.
Do you want to continue [Y/n]? ARE YOU STUPID?!?
--
I will have debian-reference in further 9 languages. But I think in long
term we will have less problems. We should start filing bugs against all
those packages we see with the above command and think they don't need
to be installed and should get the number to a minimum. 

But going this way I see a big problem on decisions if a package should
be recommended or suggested. E.g. I don't want [0] to be installed by
default but Loic seems to do so.

Regards,
Amir

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430024
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415436


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Steve Langasek]

On Wed, Aug 01, 2007 at 10:38:41PM +0200, Adeodato Simó wrote:
> > > >   Then he'll be able to move /bin/sh symlink on bash if he wants to.

> > > Right.  Hence that's the point for the user to change /bin/sh.  :)

> > > I have no problem with dash being the default.  I was just defending our
> > > committment to let the user change /bin/sh if they want to.

> >   Yes, I never thought we were about to remove the fact that /bin/sh was
> > a symlink that the user could be able to change whenever he wants. I
> > don't think debconf questions or alike are wise FWIW though.

> So how will be that achieved in a way that's persistant across upgrades,
> if both debconf and alternatives are being rejected?

diversions.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 02:18:22PM -0700, Steve Langasek wrote:
> On Wed, Aug 01, 2007 at 10:49:57PM +0200, Josselin Mouette wrote:
> > Le mercredi 01 août 2007 à 22:22 +0200, Wouter Verhelst a écrit :
> > > There are embedded environments where 80KB is a concern.
> 
> > I fail to see why you'd want to install any other shell than the
> > smallest one on such an environment.
> 
> Well, bash is essential, so you have to have that one installed or else you
> have to scan all your packages for uses of bash and convert them.

  Let's make it a release goal !

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpszBWtKn1pt.pgp
Description: PGP signature

Re: /bin/sh diversions

[Faidon Liambotis]

Wouter Verhelst wrote:
 > There are embedded environments where 80KB is a concern. We're not at
> the level yet where we can reasonably support such environments, but
> there are people who are trying to change that, and I don't think we
> should make it harder for them by setting things up in a way that isn't
> strictly necessary, but is the easy way out.
This change is for the benefit of those environments; it could be the
first step of dropping bash from Essential in favor of dash.

It's certainly doable: 2 years ago I added a lintian check and ran it on
the whole archive. Most packages are easily "fixed" (as in
work-arounded)  by adding a dependency on bash.
The challenge is on preinst/postrm scripts that use bash and should be
rewritten to avoid bashisms (e.g. mysql).

Note that I'm not advocating that since I'm not convinced (yet) that is
needed. Personally, I don't think that Debian will ever target
environments where 80KB (or 107KB) of waste in default install matters.

Regards,
Faidon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Steve Langasek]

On Wed, Aug 01, 2007 at 01:44:11PM -0700, Russ Allbery wrote:
> Adeodato Simó <[EMAIL PROTECTED]> writes:

> > So how will be that achieved in a way that's persistant across upgrades,
> > if both debconf and alternatives are being rejected?

> Can we create the symlink in the postinst of base-files or something else
> equally core, but only on initial installation or if the symlink is
> missing?

As long as the postinst of base-files doesn't have #!/bin/sh at the top, I
guess? :-)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Steve Langasek]

On Wed, Aug 01, 2007 at 10:49:57PM +0200, Josselin Mouette wrote:
> Le mercredi 01 août 2007 à 22:22 +0200, Wouter Verhelst a écrit :
> > There are embedded environments where 80KB is a concern.

> I fail to see why you'd want to install any other shell than the
> smallest one on such an environment.

Well, bash is essential, so you have to have that one installed or else you
have to scan all your packages for uses of bash and convert them.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Francesco P. Lovergine]

On Wed, Aug 01, 2007 at 09:19:34PM +0100, Neil Williams wrote:
> 
> Blindly installing all Recommends: is a BAD idea.
> 

My laptop hard disk thought the same when apt asked to install 313 more
Recommended packages and ~900MB of new files. But probably my hard disk
is a stupid piece of old fashioned hardware with a more old fashioned 
owner ...

-- 
Francesco P. Lovergine


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Reinhard Tartler]

Neil Williams <[EMAIL PROTECTED]> writes:

>> E.g. by filing bugs against package (and possibly NMU them) that
>> abuse the Recommends relationship.
>
> Like moving all Recommends: into Suggests?

Yes.

> Recommends does NOT apply to everyone - that is Policy. 

Quoting Debian Policy 7.2:

: Recommends 
:
:   This declares a strong, but not absolute, dependency.
:   The Recommends field should list packages that would be found 
:   together with this one in all but unusual installations.

> What apt is now doing is undermining Policy by removing that CHOICE to
> not use any recommended packages.

No. The apt team intends to finally implement what is mandated by Debian
Policy for years.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


pgpHzcNyNs8yT.pgp
Description: PGP signature

Re: /bin/sh diversions

[Josselin Mouette]

Le mercredi 01 août 2007 à 22:22 +0200, Wouter Verhelst a écrit :
> There are embedded environments where 80KB is a concern.

I fail to see why you'd want to install any other shell than the
smallest one on such an environment.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: /bin/sh diversions

[Russ Allbery]

Adeodato Simó <[EMAIL PROTECTED]> writes:

> So how will be that achieved in a way that's persistant across upgrades,
> if both debconf and alternatives are being rejected?

Can we create the symlink in the postinst of base-files or something else
equally core, but only on initial installation or if the symlink is
missing?  That way, it's not owned by any package and the user can simply
change it directly themselves with ln -sf if they want to, at a time of
their choosing, and we don't have to be as paranoid about how we change it
ourselves because we simply never do after the initial installation.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Installation of Recommends by default on October 1st

[Wouter Verhelst]

On Wed, Aug 01, 2007 at 07:14:14PM +0100, Neil Williams wrote:
> On Wed, 1 Aug 2007 19:28:27 +0200
> [EMAIL PROTECTED] (Marco d'Itri) wrote:
> 
> > On Aug 01, Michael Vogt <[EMAIL PROTECTED]> wrote:
> > 
> > > We, the APT Development Team, will change apt to install recommended
> > > packages by default on October 1st. This should give enough time to
> 
> > Why? What is the point?
> 
> Precisely - just what is the benefit? I really don't think this is a
> good idea. My immediate reaction is to disable recommends on all my
> boxes. Have I got to write a script now to force this decision to be
> undone whenever I install a new box? I'll certainly need something like
> that for the cross-built apt for Emdebian
> - embedded devices will not cope with this change.

You can easily drop a file in /etc/apt/apt.conf.d in some base emdebian
package, methinks. That shouldn't be too hard, no?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Adeodato Simó]

* Pierre Habouzit [Wed, 01 Aug 2007 22:30:34 +0200]:


> > >   Then he'll be able to move /bin/sh symlink on bash if he wants to.

> > Right.  Hence that's the point for the user to change /bin/sh.  :)

> > I have no problem with dash being the default.  I was just defending our
> > committment to let the user change /bin/sh if they want to.

>   Yes, I never thought we were about to remove the fact that /bin/sh was
> a symlink that the user could be able to change whenever he wants. I
> don't think debconf questions or alike are wise FWIW though.

So how will be that achieved in a way that's persistant across upgrades,
if both debconf and alternatives are being rejected?

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
 Listening to: Dido - Hunter


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 09:56:43PM +0200, Loïc Minier wrote:
> On Wed, Aug 01, 2007, Marco d'Itri wrote:
> > > We, the APT Development Team, will change apt to install recommended
> > > packages by default on October 1st. This should give enough time to
> > Why? What is the point?
> 
>  Fix Recommends!  These are nothing more than Suggests right now --
>  except in aptitude.

  Well, even if they were used properly (and we agree they aren't, see
the bug Joss filed on lighttpd e.g. ...), I'm not bought to the argument
that _apt_ should install those by default.

  I mean, recommends means that having the recommends installed may e.g.
enable some additionnal features in your package. But if the user don't
need them, then what ? he will download loads of packages for nothing ?
See openoffice.org, I think it recommends java or many things like that.
If I don't want to install java and the hundreds of megabytes it come
with, how am I supposed to do ?

apt-cache show openoffice.org-writer |grep Recom
Recommends: openoffice.org-filter-binfilter, gij | java-gcj-compat | j2re1.4 | 
java2-runtime, openoffice.org-java-common (>> 2.2.0-4)

  And really, I think this recommends like is perfectly correct, as many
features in OOo are enabled if you have java installed.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpbQ47Ytz5e8.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Wouter Verhelst]

On Wed, Aug 01, 2007 at 09:54:45PM +0200, Marco d'Itri wrote:
> On Aug 01, Reinhard Tartler <[EMAIL PROTECTED]> wrote:
> > That's just one line in your apt.conf, as described in the original
> > announcement.
> That's just one line in the apt.conf of hundred of servers.

Don't tell me you manually edit all configuration files on all your
servers.

There's been apt.conf.d since ages.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:

> This is not a question of removing choice.  This change in apt is the
> only thing that *gives* you a choice of installing recommends via apt.
> That the solution for disabling this in your use case is not immediately
> obvious is not a reason to not adopt a reasonable default in apt.

I think it's also particularly annoying for our two major recommended
package installation interfaces, aptitude and apt-get, to do the opposite
thing by default with this core of a feature.  What a recipe for
confusion for the average user who doesn't know the history and doesn't
choose them based on their Recommends-handling behavior!  We shouldn't be
substituting tool selection for configuration.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Holger Levsen]

Hi,

On Wednesday 01 August 2007 21:46, Neil Williams wrote:
> And a script to implement that in every box I have to install. Again
> and Again and Again and 

Hu? You don't change any other configuration on those boxes? Nothing??


regards,
Holger


pgps3qpDnM8C4.pgp
Description: PGP signature

Re: /bin/sh diversions

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 10:22:58PM +0200, Wouter Verhelst wrote:
> On Wed, Aug 01, 2007 at 07:11:52PM +0200, Marco d'Itri wrote:
> > On Aug 01, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > > It being the smallest and fastest one doesn't really help if you're in a
> > > tight environment where you want only one shell to be installed, and you
> > > want to use a different one from whatever Debian chose because of other
> > > reasons.
> > -rwxr-xr-x 1 root root 79956 Jul 21 12:24 /bin/dash*
> > 
> > If 80 KB are a concern then I think you have way more problems than
> > wasting disk space because two different POSIX shells are installed.
> 
> There are embedded environments where 80KB is a concern. We're not at
> the level yet where we can reasonably support such environments, but
> there are people who are trying to change that, and I don't think we
> should make it harder for them by setting things up in a way that isn't
> strictly necessary, but is the easy way out.
> 
> Note that I'm not saying that we should necessarily support it, then;
> only that "it's not useful, so sod it" isn't a very useful argument. The
> above is an example of where it would be useful.
> 
> Oh, and it's 
> 
> -rwxr-xr-x 1 root root 107K 2007-07-18 14:02 /bin/dash

  funny, on amd64 it's smaller:

┌─(22:30)
└[artemis] ll /bin/{bash,dash}
-rwxr-xr-x 1 root root 769368 2006-12-11 23:28 /bin/bash
-rwxr-xr-x 1 root root  98936 2007-07-18 11:50 /bin/dash

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpwo9TmsOd9E.pgp
Description: PGP signature

Re: /bin/sh diversions

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 01:05:37PM -0700, Russ Allbery wrote:
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > On Wed, Aug 01, 2007 at 10:57:53AM -0700, Russ Allbery wrote:
> >> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> 
> >>>   Okay, but that's not an argument. What would be the point for the user
> >>> to change /bin/sh if Debian has already chosen the fastest and smallest
> >>> one ?
> 
> >> Because Debian thinks that the smallest and fastest one is dash, but
> >> the user wants to run a giant pile of tens of thousands of lines of
> >> shell scripts that are internal to their organization, are full of
> >> bashisms, that the user isn't supposed to be changing, and which all
> >> use /bin/sh.
> 
> >   Then he'll be able to move /bin/sh symlink on bash if he wants to.
> 
> Right.  Hence that's the point for the user to change /bin/sh.  :)
> 
> I have no problem with dash being the default.  I was just defending our
> committment to let the user change /bin/sh if they want to.

  Yes, I never thought we were about to remove the fact that /bin/sh was
a symlink that the user could be able to change whenever he wants. I
don't think debconf questions or alike are wise FWIW though.

  In fact what happens currently with bash/dash is fine, just with
/bin/sh being dash instead of bash for new installations.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpzhpBG0JgA5.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Steve Langasek]

On Wed, Aug 01, 2007 at 08:46:29PM +0100, Neil Williams wrote:
> Recommends does NOT apply to everyone - that is Policy. What apt is now
> doing is undermining Policy by removing that CHOICE to not use any
> recommended packages.

No, what Policy says is:

 `Recommends'
  This declares a strong, but not absolute, dependency.

  The `Recommends' field should list packages that would be found
  together with this one in all but unusual installations.

This is quite clear that 'Recommends' is supposed to contain packages that
will be installed together with the package in the common case, which in
turn means that the default behavior for apt *should* be to install
recommended packages.

This is not a question of removing choice.  This change in apt is the only
thing that *gives* you a choice of installing recommends via apt.  That the
solution for disabling this in your use case is not immediately obvious is
not a reason to not adopt a reasonable default in apt.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Josselin Mouette]

Le mercredi 01 août 2007 à 21:19 +0100, Neil Williams a écrit :
> On Wed, 01 Aug 2007 21:57:01 +0200
> Josselin Mouette <[EMAIL PROTECTED]> wrote:
> 
> > Le mercredi 01 août 2007 à 19:14 +0100, Neil Williams a écrit :
> > > Precisely - just what is the benefit?
> > 
> > Stopping to get stupid bug reports from either users not having
> > installed Recommends: and complaining about missing functionality,
> 
> That smacks of a poor manpage/docs more than a need to *force* a change
> in apt behaviour.

Whoa ?

The problem is definitely APT not installing packages it should install
by default, or forcing to install packages that aren't entirely needed
per se. This is a problem in APT and I'm glad to see it fixed in APT.

> apt does NOT install Recommends: by default but it DOES give more
> information on what the recommended packages can actually DO and this
> information is also available to reportbug etc.?

Multiply it by 1000 packages and no one will read it.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Installation of Recommends by default on October 1st

[Bernd Zeimetz]

> Currently, all you see is a package name - if the default apt behaviour
> was to display the description (ala aptitude) then the user can make an
> intelligent choice. 

If the user is able to make an intelligent choice. Even after displaying
the long description for the Recommended packages, a lot of user have no
clue if they need the packages. Better leave that to people like you,
who know what they do.

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Questions on a OS

[Mihail Yakimenko]

Me call Mikhail im designers. I drew and devised (that also as works)  
exterior view OS. But im not programist. Im from the childhood to  
mechtayu about such a OS. Possibly whether that association to me  
pomozhet?



С уважением Михаил Якименко
[EMAIL PROTECTED]

Re: /bin/sh diversions

[Wouter Verhelst]

On Wed, Aug 01, 2007 at 07:11:52PM +0200, Marco d'Itri wrote:
> On Aug 01, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > It being the smallest and fastest one doesn't really help if you're in a
> > tight environment where you want only one shell to be installed, and you
> > want to use a different one from whatever Debian chose because of other
> > reasons.
> -rwxr-xr-x 1 root root 79956 Jul 21 12:24 /bin/dash*
> 
> If 80 KB are a concern then I think you have way more problems than
> wasting disk space because two different POSIX shells are installed.

There are embedded environments where 80KB is a concern. We're not at
the level yet where we can reasonably support such environments, but
there are people who are trying to change that, and I don't think we
should make it harder for them by setting things up in a way that isn't
strictly necessary, but is the easy way out.

Note that I'm not saying that we should necessarily support it, then;
only that "it's not useful, so sod it" isn't a very useful argument. The
above is an example of where it would be useful.

Oh, and it's 

-rwxr-xr-x 1 root root 107K 2007-07-18 14:02 /bin/dash

;-P

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Neil Williams]

On Wed, 01 Aug 2007 21:57:01 +0200
Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le mercredi 01 août 2007 à 19:14 +0100, Neil Williams a écrit :
> > Precisely - just what is the benefit?
> 
> Stopping to get stupid bug reports from either users not having
> installed Recommends: and complaining about missing functionality,

That smacks of a poor manpage/docs more than a need to *force* a change
in apt behaviour.

Sledgehammer vs nut anyone?

What about a different solution:

apt does NOT install Recommends: by default but it DOES give more
information on what the recommended packages can actually DO and this
information is also available to reportbug etc.?

Currently, all you see is a package name - if the default apt behaviour
was to display the description (ala aptitude) then the user can make an
intelligent choice. I may even install one or two Recommends: myself
but I need to know WHY foobar5 is useful in the first place.

This should NOT be a forced change, it should not have to be a
system-wide opt-out implemented on every single machine again and
again. It should be a method to support an informed choice.

Blindly installing all Recommends: is a BAD idea.

> or
> users complaining about non-essential Depends: bloating their disk
> space.

On that, will apt be given an autorecommendremove option to complement
this change? Recommends: should not be a blanket imposition. Users and
system admins need a method of opting out of Recommends at any stage -
preferably right at the start but also to strip out unwanted bloat at
any later stage too.

I still think this is simply the wrong thing to do with apt.

Fixing Recommends: is *not* sufficient justification IMHO.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpZN9aEzPqOB.pgp
Description: PGP signature

Re: /bin/sh diversions

[Thorsten Glaser]

Mike Hommey dixit:

>Yeah, they should be given solaris's /bin/sh.

That's a Bourne shell, not a POSIX shell. Try /usr/xpg4/bin/sh there.

//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Wed, Aug 01, 2007, Marco d'Itri wrote:
> We have frontends like aptitude to automatically install recommends.

 and it's the single frontend doing this: synaptic + apt-get are very
 common and there was no reason to duplicate this logic in all
 frontends.

> Why was such a huge change, totally opposed to ten years of customs,
> implemented without a discussion on debian-devel?

 It was discussed:



 and this only sets a target date for fixing our archive, the change is
 not effective yet, and even when it will affect sid, there will still
 be time to fix any bad recommends before the release.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Russ Allbery]

Pierre Habouzit <[EMAIL PROTECTED]> writes:
> On Wed, Aug 01, 2007 at 10:57:53AM -0700, Russ Allbery wrote:
>> Pierre Habouzit <[EMAIL PROTECTED]> writes:

>>>   Okay, but that's not an argument. What would be the point for the user
>>> to change /bin/sh if Debian has already chosen the fastest and smallest
>>> one ?

>> Because Debian thinks that the smallest and fastest one is dash, but
>> the user wants to run a giant pile of tens of thousands of lines of
>> shell scripts that are internal to their organization, are full of
>> bashisms, that the user isn't supposed to be changing, and which all
>> use /bin/sh.

>   Then he'll be able to move /bin/sh symlink on bash if he wants to.

Right.  Hence that's the point for the user to change /bin/sh.  :)

I have no problem with dash being the default.  I was just defending our
committment to let the user change /bin/sh if they want to.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Bernd Zeimetz]

> No - because the default is already in place in aptitude which is WHY I
> don't use aptitude. If apt goes the same way, the default configuration
> of each offers no choice.
> 
> By the time I get a chance to switch that option off, the installation
> has added loads of JUNK that I do NOT want.

but when aptitude came up with that setting a lot of Recommends: should
have been in Suggests: instead. I think it's a really good idea to
install Recommends: by default, but the Maintainers may not mess with it.
For example you ahve package foo which needs package bar in 99% of the
cases, but you want to allow people to replace bar byt something else,
probably on a remote machine - so they don't need to install bar on the
machine with foo - imho that's a pretty common thing.

But indeed, Recommends: needs a major cleanup before the switch happens.
Also a d-i or debconf question while installing the system would be
really appreciated, as I do not want to install the recommended packages
on all systems, but on most.


Cheers,

Bernd
-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Josselin Mouette]

Le mercredi 01 août 2007 à 19:14 +0100, Neil Williams a écrit :
> Precisely - just what is the benefit?

Stopping to get stupid bug reports from either users not having
installed Recommends: and complaining about missing functionality, or
users complaining about non-essential Depends: bloating their disk
space.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Wed, Aug 01, 2007, Marco d'Itri wrote:
> > We, the APT Development Team, will change apt to install recommended
> > packages by default on October 1st. This should give enough time to
> Why? What is the point?

 Fix Recommends!  These are nothing more than Suggests right now --
 except in aptitude.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Marco d'Itri]

On Aug 01, Reinhard Tartler <[EMAIL PROTECTED]> wrote:

> TBH, I think this is a very good idea. There are a lot of cases in the
> debian archive, were the package maintainer wants to express that a
> related package should really be installed by default, but is not really
> necessary in all cases. Moreover, in some cases it makes sense to
We have frontends like aptitude to automatically install recommends.
Why was such a huge change, totally opposed to ten years of customs,
implemented without a discussion on debian-devel?

> That's just one line in your apt.conf, as described in the original
> announcement.
That's just one line in the apt.conf of hundred of servers.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Wed, Aug 01, 2007, Neil Williams wrote:
> Recommends does NOT apply to everyone - that is Policy. What apt is now
> doing is undermining Policy by removing that CHOICE to not use any
> recommended packages.

 It's the other way around; in the last months, I bumped plenty of
 Recommends to *Depends* because I received too many reports about this
 or that nor working by default.  Practically speaking, "Recommends" is
 unusable in the current state of things, and it finally will mean
 something, thanks to this change.  What you're asking for already
 exists: it's Suggests; we don't need a second Suggests.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Neil Williams]

On Wed, 01 Aug 2007 20:45:44 +0200
Reinhard Tartler <[EMAIL PROTECTED]> wrote:

> > Precisely - just what is the benefit? I really don't think this is a
> > good idea. 
> 
> TBH, I think this is a very good idea. There are a lot of cases in the
> debian archive, were the package maintainer wants to express that a
> related package should really be installed by default, but is not
> really necessary in all cases. 

Precisely - I am one of those cases and I don't think there are as few
users in this situation as may be envisaged.

> Moreover, in some cases it makes sense
> to uninstall that related package. Stressing the 'Recommends'
> relationship as mandated by current policy by installing them by
> default in apt it therefore a very good idea.

No, it is a very bad idea.
 
> > My immediate reaction is to disable recommends on all my
> > boxes. Have I got to write a script now to force this decision to be
> > undone whenever I install a new box?
> 
> That's just one line in your apt.conf, as described in the original
> announcement.

And a script to implement that in every box I have to install. Again
and Again and Again and 

You almost forcing me into maintaining a fork of apt that restores the
current behaviour from the very start.

> > If I wanted Recommends:, I'd use aptitude - I see no sense in
> > forcing this.
> 
> You can turn it the other way round: If you don't want recommends,
> just turn it of, the same way as you do it with aptitude.

No - because the default is already in place in aptitude which is WHY I
don't use aptitude. If apt goes the same way, the default configuration
of each offers no choice.

By the time I get a chance to switch that option off, the installation
has added loads of JUNK that I do NOT want.
 
> > I tried the sample commands and apt wanted to add HALF A GIGABYTE of
> > unnecessary stuff!!! Others may consider hard disc space cheap but,
> > in truth, hard disc space is not infinite.
> >
> > Please, please, please, reconsider.
> 
> Please stop whining and start contributing. 

? do you think I don't contribute already ? Don't go down that road, OK?
Just don't.

> E.g. by filing bugs
> against package (and possibly NMU them) that abuse the Recommends
> relationship.

Like moving all Recommends: into Suggests?

I don't want ANY recommends installed by default - not even as udebs. I
want to make the choice about what gets installed from the very first
stage. I'm sure I'm not alone.

Recommends does NOT apply to everyone - that is Policy. What apt is now
doing is undermining Policy by removing that CHOICE to not use any
recommended packages.

-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


pgpZAeClJnMfL.pgp
Description: PGP signature

Re: /bin/sh diversions

[Mike Hommey]

On Wed, Aug 01, 2007 at 07:05:32PM +, Thorsten Glaser <[EMAIL PROTECTED]> 
wrote:
> Henrique de Moraes Holschuh dixit:
> 
> >OTOH, specifically using something else than /bin/sh for a fast
> >POSIX-with-the-extensions-Debian-mandates shell
> 
> No, that will not make sense. People who write #!/bin/sh scripts
> should be tought that they can only use so-and-so few things.

Yeah, they should be given solaris's /bin/sh.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Thorsten Glaser]

Henrique de Moraes Holschuh dixit:

>OTOH, specifically using something else than /bin/sh for a fast
>POSIX-with-the-extensions-Debian-mandates shell

No, that will not make sense. People who write #!/bin/sh scripts
should be tought that they can only use so-and-so few things.

//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 08:45:44PM +0200, Reinhard Tartler wrote:
> Neil Williams <[EMAIL PROTECTED]> writes:
> > On Wed, 1 Aug 2007 19:28:27 +0200 [EMAIL PROTECTED] (Marco d'Itri) wrote:
> > > On Aug 01, Michael Vogt <[EMAIL PROTECTED]> wrote:
> > >
> > > > We, the APT Development Team, will change apt to install recommended
> > > > packages by default on October 1st. This should give enough time to
> >
> > > Why? What is the point?
> >
> > Precisely - just what is the benefit? I really don't think this is a
> > good idea. 
>
> TBH, I think this is a very good idea.

  I disagree, but OTOH I'm not a random average user. Users expect every
feature of the software they install to work properly, and don't know
what to install for it to work. I do, and I care about my daily upgrades
to being fast, and for that I need to minimize the number of packages I
install.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp47DSqIbqW8.pgp
Description: PGP signature

Re: /bin/sh diversions

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 10:57:53AM -0700, Russ Allbery wrote:
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> 
> >   Okay, but that's not an argument. What would be the point for the user
> > to change /bin/sh if Debian has already chosen the fastest and smallest
> > one ?
> 
> Because Debian thinks that the smallest and fastest one is dash, but the
> user wants to run a giant pile of tens of thousands of lines of shell
> scripts that are internal to their organization, are full of bashisms,
> that the user isn't supposed to be changing, and which all use /bin/sh.

  Then he'll be able to move /bin/sh symlink on bash if he wants to. Or
enhance dash to support the very few bashisms that are often used.
(echo -e, the {a,b,c} globbing and [[ ]], I checked, those three are
*trivial* to implement).

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpEylJlMBwjh.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Gustavo Franco]

On 8/1/07, Reinhard Tartler <[EMAIL PROTECTED]> wrote:
> Neil Williams <[EMAIL PROTECTED]> writes:
>
> (...)
> > I tried the sample commands and apt wanted to add HALF A GIGABYTE of
> > unnecessary stuff!!! Others may consider hard disc space cheap but, in
> > truth, hard disc space is not infinite.
> >
> > Please, please, please, reconsider.
>
> Please stop whining and start contributing. E.g. by filing bugs against
> package (and possibly NMU them) that abuse the Recommends relationship.

I would like to point out that pkg-gnome team already fixed the
gnome-dbg related Recommends in svn; for those with
gnome-desktop-environment installed if it was October 1st, it would
install all the debug enabled packages. Lots of people using GNOME
will see half a gigabyte results that will mean nothing once apt
development team do the change they're planning.

regards,
-- stratus
http://stratusandtheswirl.blogspot.com
get debian @ http://get.debian.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Reinhard Tartler]

Neil Williams <[EMAIL PROTECTED]> writes:

> On Wed, 1 Aug 2007 19:28:27 +0200
> [EMAIL PROTECTED] (Marco d'Itri) wrote:
>
>> On Aug 01, Michael Vogt <[EMAIL PROTECTED]> wrote:
>> 
>> > We, the APT Development Team, will change apt to install recommended
>> > packages by default on October 1st. This should give enough time to
>
>> Why? What is the point?
>
> Precisely - just what is the benefit? I really don't think this is a
> good idea. 

TBH, I think this is a very good idea. There are a lot of cases in the
debian archive, were the package maintainer wants to express that a
related package should really be installed by default, but is not really
necessary in all cases. Moreover, in some cases it makes sense to
uninstall that related package. Stressing the 'Recommends' relationship
as mandated by current policy by installing them by default in apt it
therefore a very good idea.

> My immediate reaction is to disable recommends on all my
> boxes. Have I got to write a script now to force this decision to be
> undone whenever I install a new box?

That's just one line in your apt.conf, as described in the original
announcement.

> I'll certainly need something like that for the cross-built apt for
> Emdebian - embedded devices will not cope with this change.

Feel free. As said, it is just one line in the config.

> Why can't this be a debconf selection (with a default of OFF)! I see no
> reason to make it mandatory for new installations, let alone every
> upgrade to existing boxes.

I don't see the necessity to add debconf to the apt maintainer
scripts. If it was to be added, it should default to on, since it
implements the current policy.

> If I wanted Recommends:, I'd use aptitude - I see no sense in forcing
> this.

You can turn it the other way round: If you don't want recommends, just
turn it of, the same way as you do it with aptitude.

> I tried the sample commands and apt wanted to add HALF A GIGABYTE of
> unnecessary stuff!!! Others may consider hard disc space cheap but, in
> truth, hard disc space is not infinite.
>
> Please, please, please, reconsider.

Please stop whining and start contributing. E.g. by filing bugs against
package (and possibly NMU them) that abuse the Recommends relationship.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


pgpcP4xwux5TB.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Neil Williams]

On Wed, 1 Aug 2007 19:28:27 +0200
[EMAIL PROTECTED] (Marco d'Itri) wrote:

> On Aug 01, Michael Vogt <[EMAIL PROTECTED]> wrote:
> 
> > We, the APT Development Team, will change apt to install recommended
> > packages by default on October 1st. This should give enough time to

> Why? What is the point?

Precisely - just what is the benefit? I really don't think this is a
good idea. My immediate reaction is to disable recommends on all my
boxes. Have I got to write a script now to force this decision to be
undone whenever I install a new box? I'll certainly need something like
that for the cross-built apt for Emdebian
- embedded devices will not cope with this change.

Why can't this be a debconf selection (with a default of OFF)! I see no
reason to make it mandatory for new installations, let alone every
upgrade to existing boxes.

If I wanted Recommends:, I'd use aptitude - I see no sense in forcing
this.

I tried the sample commands and apt wanted to add HALF A GIGABYTE of
unnecessary stuff!!! Others may consider hard disc space cheap but, in
truth, hard disc space is not infinite.

Please, please, please, reconsider.

-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


pgpSdkqwHyN9a.pgp
Description: PGP signature

Re: /bin/sh diversions

[Russ Allbery]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

>   Okay, but that's not an argument. What would be the point for the user
> to change /bin/sh if Debian has already chosen the fastest and smallest
> one ?

Because Debian thinks that the smallest and fastest one is dash, but the
user wants to run a giant pile of tens of thousands of lines of shell
scripts that are internal to their organization, are full of bashisms,
that the user isn't supposed to be changing, and which all use /bin/sh.

This sort of thing unfortunately happens a lot.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Marco d'Itri]

On Aug 01, Pierre Habouzit <[EMAIL PROTECTED]> wrote:

>   * the one unclever users have written with /bin/sh pointing to
> /bin/bash. For them, it's easy, just don't change /bin/sh on dash on
> upgrades. Do that only for new installations. And for them, the fix
> is quite easy, they still can use #!/bin/bash.
This helps dealing with the odd broken proprietary package which uses
bashisms: http://www.linux.it/~md/software/switchsh.c.gz

 * This program creates a new filesystem namespace, bind mounts /bin/bash
 * over /bin/sh and runs its arguments.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: stupid dependencies on update-inetd

[Russ Allbery]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> So far this case has not been handled automatically and I do not think
> it is worth supporting because it would require creating stand-alone
> update-inetd packages for each kind of inetd.

I'm not at all surprised if there's some problem with the idea of having
inet-superservers that provide their own update-inetd Providing and
Conflicting with update-inetd, but if someone could explain the problem to
me, I'd really appreciate it.  I'd learn more about how these things work
(and virtual packages is an area where my understanding is a bit weak).

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Marco d'Itri]

On Aug 01, Michael Vogt <[EMAIL PROTECTED]> wrote:

> We, the APT Development Team, will change apt to install recommended
> packages by default on October 1st. This should give enough time to
Why? What is the point?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: /bin/sh diversions

[Marco d'Itri]

On Aug 01, Thorsten Glaser <[EMAIL PROTECTED]> wrote:

> Until now, /bin/sh used to be a symbolic link to /bin/bash, unless dash and,
> later, mksh offered to install themselves there instead, as per Debian poli-
> cy, which states that all POSIX compatible shells can be used as /bin/sh.
Bad idea since there is no point at all in using something else than
bash (the standard, which works with everything) or dash (much faster,
but rarely will break some buggy package).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: /bin/sh diversions

[Marco d'Itri]

On Aug 01, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> It being the smallest and fastest one doesn't really help if you're in a
> tight environment where you want only one shell to be installed, and you
> want to use a different one from whatever Debian chose because of other
> reasons.
-rwxr-xr-x 1 root root 79956 Jul 21 12:24 /bin/dash*

If 80 KB are a concern then I think you have way more problems than
wasting disk space because two different POSIX shells are installed.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: stupid dependencies on update-inetd

[Marco d'Itri]

On Aug 01, Steve Langasek <[EMAIL PROTECTED]> wrote:

> > Again, the update-inetd interface is formally provided by
> > inet-superserver and not by update-inetd.
> So there's no allowance for a package that wants to interface with inetd if
> it's installed, but doesn't depend on inetd being installed?
So far this case has not been handled automatically and I do not think
it is worth supporting because it would require creating stand-alone
update-inetd packages for each kind of inetd.
I also do not think it is a very /useful/ feature since I cannot see a
big difference between editing /etc/inetd.conf to uncomment a line and
editing /etc/inetd.conf to paste a line from README.Debian.

> > > But I would still like input on the use of this dependency for samba; I
> > > rather expect we would get complaints if samba depended on 
> > > inet-superserver
> > > when it doesn't use it in the default configuration.
> > Do not depend on the presence of /usr/sbin/update-inetd then.
> How should idempotent maintainer scripts that call update-inetd work
> otherwise?  I'd rather not leave cruft around in /etc/inetd.conf as a
> consequence of inet-superserver not being installed at the right moment.
As usual, do not call update-inetd then.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: /bin/sh diversions

[Joey Hess]

Thorsten Glaser wrote:
> http://www.fifi.org/doc/debconf-doc/tutorial.html

This document is ancient and out of date. Please use the
debconf-devel(7) man page (in debconf-doc) instead.

-- 
see shy jo


signature.asc
Description: Digital signature

Resolved bugs keeping packages out of testing?

[John Goerzen]

Hi,

I have several "excuses" pages that resemble this one:

http://qa.debian.org/excuses.php?package=darcs-buildpackage

This says that darcs-buildpackage has new bugs, and references #410838.  But 
#410838 is resolved in unstable and has been for ages -- since February.  
Why is that still a reason to keep it out of testing?

Also, what's up with mips and mipsel?  Many of my packages are kept out of 
testing because they're out of date on those archs.

-- John


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 06:11:48PM +0200, Josselin Mouette wrote:
> Le mercredi 01 août 2007 à 18:00 +0200, Pierre Habouzit a écrit :
> >   And wrt scripts out there, there is 2 kinds of scripts:
> >   * the old one that are written by people on obsolete platforms where
> > the de facto standard was a local ksh shell, and we can expect those
> > to work properly on dash.
> 
> Well, no, ksh has some extensions to POSIX. AFAIK most if not all of
> them work with bash, so using /bin/bash looks like the solution for
> these scripts.

  Afaict AIX ksh has not _that_ many exensions, and dash implement most
of them.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpTpCgAPDal9.pgp
Description: PGP signature

Re: Resolved bugs keeping packages out of testing?

[John Goerzen]

On Wed August 1 2007 11:04:04 am Pierre Habouzit wrote:
>   http://buildd.debian.org/~jeroen/status/package.php?p=haskell-configfile
> and that it's a dependency of yours.


Yeah, I noticed that part.  Actually it appears that GHC is generating 
binaries that are crashing with a bus error on that platform, which is the 
root cause.  I just wondered why the bugs were showing up, because they 
shouldn't be.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Josselin Mouette]

Le mercredi 01 août 2007 à 18:00 +0200, Pierre Habouzit a écrit :
>   And wrt scripts out there, there is 2 kinds of scripts:
>   * the old one that are written by people on obsolete platforms where
> the de facto standard was a local ksh shell, and we can expect those
> to work properly on dash.

Well, no, ksh has some extensions to POSIX. AFAIK most if not all of
them work with bash, so using /bin/bash looks like the solution for
these scripts.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Resolved bugs keeping packages out of testing?

[Adeodato Simó]

* John Goerzen [Wed, 01 Aug 2007 10:56:08 -0500]:

> Hi,

> I have several "excuses" pages that resemble this one:

> http://qa.debian.org/excuses.php?package=darcs-buildpackage

> This says that darcs-buildpackage has new bugs, and references #410838.  But 
> #410838 is resolved in unstable and has been for ages -- since February.  
> Why is that still a reason to keep it out of testing?

Without being a bugscan/britney hacker, I think what's happening it's
that #410838 is being counted precisely because the fixed version is not
built on mips. Once it's built there, the package will no longer be
considered buggy.

> Also, what's up with mips and mipsel?  Many of my packages are kept out of 
> testing because they're out of date on those archs.

Many build failures due to uninstallable stuff has been queuing up
lately. I've gone over a lot of them in the past days, but darcs-buildpackage
did not show in my list of otherwise-ready packages, precisely because
it was not built on mipsel. Heh.

I'll ask for a retry.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Listening to: Radio Futura - Condena de amor


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Josselin Mouette]

Le mercredi 01 août 2007 à 13:22 +, Thorsten Glaser a écrit :
> While I don't have an issue with dash being the default /bin/sh we should
> implement a mechanism for the user to select which shell he wants there,
> via debconf. 

I don't think so, no.

The default shell should be dash and there is no reason to make it
configurable. If a user wants to shoot himself in the foot by changing
it, that's fine, but we shouldn't provide a system which has the
smallest chance of breaking /bin/sh.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: /bin/sh diversions

[Wouter Verhelst]

On Wed, Aug 01, 2007 at 05:47:59PM +0200, Pierre Habouzit wrote:
> On Wed, Aug 01, 2007 at 02:59:13PM +, Thorsten Glaser wrote:
> > Pierre Habouzit dixit:
> > 
> > >I don't see a valid reason for the
> > >user to chose what lies behind /bin/sh.
> > 
> > Debian policy allows it.
> 
>   Okay, but that's not an argument. What would be the point for the user
> to change /bin/sh if Debian has already chosen the fastest and smallest
> one ?

It being the smallest and fastest one doesn't really help if you're in a
tight environment where you want only one shell to be installed, and you
want to use a different one from whatever Debian chose because of other
reasons.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Resolved bugs keeping packages out of testing?

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 10:56:08AM -0500, John Goerzen wrote:
> Hi,
> 
> I have several "excuses" pages that resemble this one:
> 
> http://qa.debian.org/excuses.php?package=darcs-buildpackage
> 
> This says that darcs-buildpackage has new bugs, and references #410838.  But 
> #410838 is resolved in unstable and has been for ages -- since February.  
> Why is that still a reason to keep it out of testing?
> 
> Also, what's up with mips and mipsel?  Many of my packages are kept out of 
> testing because they're out of date on those archs.

  just look at http://bjorn.haxx.se/debian/testing.pl?package=darcs-buildpackage

  I don't know why qa.d.o shows the bug as an excuse, but the issue
seems to be that your package does not build on mips:
  
http://buildd.debian.org/~jeroen/status/package.php?p=darcs-buildpackage&suite=unstable
especially because haskell-configfile does not builds either:
  http://buildd.debian.org/~jeroen/status/package.php?p=haskell-configfile
and that it's a dependency of yours.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgphBpNB0OVu3.pgp
Description: PGP signature

Re: Resolved bugs keeping packages out of testing?

[Julien Cristau]

On Wed, Aug  1, 2007 at 10:56:08 -0500, John Goerzen wrote:

> http://qa.debian.org/excuses.php?package=darcs-buildpackage
> 
> This says that darcs-buildpackage has new bugs, and references #410838.  But 
> #410838 is resolved in unstable and has been for ages -- since February.  

It's not.  unstable still has darcs-buildpackage 0.5.10 on mips, which
is affected.  As soon as the package is built on mips, the bug will be
marked as fixed in unstable, allowing the transition to testing.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: /bin/sh diversions

[Loïc Minier]

On Wed, Aug 01, 2007, Pierre Habouzit wrote:
>   Okay, but that's not an argument. What would be the point for the user
> to change /bin/sh if Debian has already chosen the fastest and smallest
> one ?

 While we're at it, could we please set the freedesktop compatible
 environment to Xfce?

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 12:53:03PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 01 Aug 2007, Thorsten Glaser wrote:
> > Henrique de Moraes Holschuh dixit:
> > >There is just too much crap out there that thinks /bin/sh is bash.
> > 
> > Not in Debian ??? /bin/sh scripts must be POSIX compliant and not use
> 
> No, not in Debian.
> 
> But in practice, if many people can't change that away from bash because all
> sort of *broken* local scripts, and 3rd-party scripts croak, you gain
> little.
> 
> OTOH, specifically using something else than /bin/sh for a fast
> POSIX-with-the-extensions-Debian-mandates shell (i.e. forget posh, but dash
> is good) does NOT need /bin/sh to point to it, so it can't trip on such
> issues caused by external factors outside of Debian's control.

  Afaict ubuntu did the change, and the sky didn't fell apart.

  And wrt scripts out there, there is 2 kinds of scripts:
  * the old one that are written by people on obsolete platforms where
the de facto standard was a local ksh shell, and we can expect those
to work properly on dash.
  * the one unclever users have written with /bin/sh pointing to
/bin/bash. For them, it's easy, just don't change /bin/sh on dash on
upgrades. Do that only for new installations. And for them, the fix
is quite easy, they still can use #!/bin/bash.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpgDApc4qpyt.pgp
Description: PGP signature

Re: /bin/sh diversions

[Henrique de Moraes Holschuh]

On Wed, 01 Aug 2007, Thorsten Glaser wrote:
> Henrique de Moraes Holschuh dixit:
> >There is just too much crap out there that thinks /bin/sh is bash.
> 
> Not in Debian ??? /bin/sh scripts must be POSIX compliant and not use

No, not in Debian.

But in practice, if many people can't change that away from bash because all
sort of *broken* local scripts, and 3rd-party scripts croak, you gain
little.

OTOH, specifically using something else than /bin/sh for a fast
POSIX-with-the-extensions-Debian-mandates shell (i.e. forget posh, but dash
is good) does NOT need /bin/sh to point to it, so it can't trip on such
issues caused by external factors outside of Debian's control.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 02:59:13PM +, Thorsten Glaser wrote:
> Pierre Habouzit dixit:
> 
> >I don't see a valid reason for the
> >user to chose what lies behind /bin/sh.
> 
> Debian policy allows it.

  Okay, but that's not an argument. What would be the point for the user
to change /bin/sh if Debian has already chosen the fastest and smallest
one ?

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp503PPCMO0a.pgp
Description: PGP signature

Re: /bin/sh diversions

[Thorsten Glaser]

Henrique de Moraes Holschuh dixit:

>There is just too much crap out there that thinks /bin/sh is bash.

Not in Debian – /bin/sh scripts must be POSIX compliant and not use
extensions, and with my experience from mksh (minus the “stop” alias
issue, which, with mksh R30, became a non-issue), and seeing how many
people use dash, there are no /bin/sh scripts that assume bash any more.

//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Re: /bin/sh diversions

[Bernd Zeimetz]

> Indeed, since #!/bin/sh scripts must not use non-POSIX features.
> Nevertheless, it _is_ possible to change /bin/sh.
>   

.. and if the user changes the /bin/sh link, it is not the distributions
fault if things break. On the other side, it's probably morea easy for
users and less error-prone if there're sane alternatives provided.


Cheers,

Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Thorsten Glaser]

Pierre Habouzit dixit:

>I don't see a valid reason for the
>user to chose what lies behind /bin/sh.

Debian policy allows it.

>If he wants to use his favourite
>sh shell features in his scripts, he shall use #!/bin/favouritesh and

Indeed, since #!/bin/sh scripts must not use non-POSIX features.
Nevertheless, it _is_ possible to change /bin/sh.

//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MD5sum failure of dpkg 1.14.5 (i386)

[Martin Wuertele]

* Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> [2007-08-01 15:36]:

> I was just doing a pbuider --update, it surprisingly failed due to a mismatch
> MD5 sum in dpkg.
> 
> From the Release file:
> MD5sum: 7f4c3b629592a0ab17c924eff9795c4c
> SHA1: 40841d015920902a9b0051f1a4296113cc474490
> SHA256: 4911981eaaee82b381b513ca0f41dc63a8be2b5c7bf0ba8f6cd6454ee8f3acf0 
> 
> From the downloaded file [1]:
> $ md5sum dpkg_1.14.5_i386.deb
> fc1091a81caee1bdab8dcb0c61f55e6e  dpkg_1.14.5_i386.deb
> $ sha1sum dpkg_1.14.5_i386.deb
> 38b69116a6d817c37400c9c5b4fc3eff241fa648  dpkg_1.14.5_i386.deb
 
$ wget http://ftp.debian.org/debian/pool/main/d/dpkg/dpkg_1.14.5_i386.deb
(...)
$ md5sum dpkg_1.14.5_i386.deb
7f4c3b629592a0ab17c924eff9795c4c  dpkg_1.14.5_i386.deb
$ sha1sum dpkg_1.14.5_i386.deb
40841d015920902a9b0051f1a4296113cc474490  dpkg_1.14.5_i386.deb
$ sha256sum dpkg_1.14.5_i386.deb
4911981eaaee82b381b513ca0f41dc63a8be2b5c7bf0ba8f6cd6454ee8f3acf0  
dpkg_1.14.5_i386.deb

yours Martin
-- 
http://martin.wuertele.net/ -- Debian -- OFTC -- SPI -- [EMAIL PROTECTED]
 AARRGLLL!
 Da gibt es ein "Welche Linux Distribution ist fuer dich die
richtige"-Quiz, und die schalgen mir Ubuntu vor!

Re: /bin/sh diversions

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 10:46:32AM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 01 Aug 2007, Pierre Habouzit wrote:
> >   debconf is definitely not the proper way. Using alternatives is.
> 
> Remember you are dealing with essential stuff.
> 
> /bin/sh must *NEVER*, not even for a milli-second, be unavailable.  You are
> only to change it using atomic operations, and when you are *completely*
> sure it will work after the operation completes.

  agreed. In fact, after some pondering, I think /bin/sh should be dash,
because it's fast, and isn't crippled wrt nss modules (allowing /var to
be unmounted when nscd is used e.g.). I don't see a valid reason for the
user to chose what lies behind /bin/sh. If he wants to use his favourite
sh shell features in his scripts, he shall use #!/bin/favouritesh and
done.

  I can't care less if /bin/sh is dash, posh or mksh. It just has to be
a posix shell, _and_ a fast one. That rules bash out[1], that's all I
can tell.

  [1] I know bash isn't _That_ slow, it's very slow to start, hence is a
  bad choice for a /bin/sh that often interprets very short lived
  scripts.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpzJP60mK42T.pgp
Description: PGP signature

Re: /bin/sh diversions

[Henrique de Moraes Holschuh]

On Wed, 01 Aug 2007, Pierre Habouzit wrote:
>   debconf is definitely not the proper way. Using alternatives is.

Remember you are dealing with essential stuff.

/bin/sh must *NEVER*, not even for a milli-second, be unavailable.  You are
only to change it using atomic operations, and when you are *completely*
sure it will work after the operation completes.

I'd much prefer to have all our scripts using something else
(/bin/debian-sh, maybe) since we can verify them to be non-broken and fix
it -- and have that be dash by default, since it is MUCH faster and less of
a resource-hog than bash.

There is just too much crap out there that thinks /bin/sh is bash.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 01:22:19PM +, Thorsten Glaser wrote:
> Hi everyone,
> 
> as shown in http://thread.gmane.org/gmane.linux.debian.devel.release/17423
> there's currently a discussion to use dash as /bin/sh instead of GNU bash.
> 
> Until now, /bin/sh used to be a symbolic link to /bin/bash, unless dash and,
> later, mksh offered to install themselves there instead, as per Debian poli-
> cy, which states that all POSIX compatible shells can be used as /bin/sh.
> 
> While I don't have an issue with dash being the default /bin/sh we should
> implement a mechanism for the user to select which shell he wants there,
> via debconf. Luckily, the Debconf tutorial by Joey Hess, found online at
> http://www.fifi.org/doc/debconf-doc/tutorial.html, has shown a sample for
> packages to do it (scroll down to “Choosing among related packages”).
> 
> I propose that bash, dash, mksh, AT&T ksh and possibly ksh get amended by
> such template. As I gather from the tutorial (please correct me if I'm
> wrong), all packages involved would have to have the exact same debconf
> choices, scripts and PO files. So I'd be more at rest if someone who is
> really familiar with debconf and po-debconf were the one to start this,
> with upgrade paths for the already existing ash (ancient), dash and mksh
> choices.
> 
> If Debian is not going to implement this choice, you'd probably have to
> change the policy which _does_ allow users to use any POSIX compatible
> shell as /bin/sh.
> 
> Please Cc: me on answers, as I'm not subscribed to this mailing list.
> Thanks in advance!
> 
> I'm not a Debian developer, I just maintain the mksh package because
> I'm the upstream author of mksh. (Testing is done on kfreebsd-i386 sid.)

  debconf is definitely not the proper way. Using alternatives is.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpNxL3ZIlm9x.pgp
Description: PGP signature

/bin/sh diversions

[Thorsten Glaser]

Hi everyone,

as shown in http://thread.gmane.org/gmane.linux.debian.devel.release/17423
there's currently a discussion to use dash as /bin/sh instead of GNU bash.

Until now, /bin/sh used to be a symbolic link to /bin/bash, unless dash and,
later, mksh offered to install themselves there instead, as per Debian poli-
cy, which states that all POSIX compatible shells can be used as /bin/sh.

While I don't have an issue with dash being the default /bin/sh we should
implement a mechanism for the user to select which shell he wants there,
via debconf. Luckily, the Debconf tutorial by Joey Hess, found online at
http://www.fifi.org/doc/debconf-doc/tutorial.html, has shown a sample for
packages to do it (scroll down to “Choosing among related packages”).

I propose that bash, dash, mksh, AT&T ksh and possibly ksh get amended by
such template. As I gather from the tutorial (please correct me if I'm
wrong), all packages involved would have to have the exact same debconf
choices, scripts and PO files. So I'd be more at rest if someone who is
really familiar with debconf and po-debconf were the one to start this,
with upgrade paths for the already existing ash (ancient), dash and mksh
choices.

If Debian is not going to implement this choice, you'd probably have to
change the policy which _does_ allow users to use any POSIX compatible
shell as /bin/sh.

Please Cc: me on answers, as I'm not subscribed to this mailing list.
Thanks in advance!

I'm not a Debian developer, I just maintain the mksh package because
I'm the upstream author of mksh. (Testing is done on kfreebsd-i386 sid.)

bye,
//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

MD5sum failure of dpkg 1.14.5 (i386)

[Javier Fernández-Sanguino Peña]

I was just doing a pbuider --update, it surprisingly failed due to a mismatch
MD5 sum in dpkg.

From the Release file:
MD5sum: 7f4c3b629592a0ab17c924eff9795c4c
SHA1: 40841d015920902a9b0051f1a4296113cc474490
SHA256: 4911981eaaee82b381b513ca0f41dc63a8be2b5c7bf0ba8f6cd6454ee8f3acf0 

From the downloaded file [1]:
$ md5sum dpkg_1.14.5_i386.deb
fc1091a81caee1bdab8dcb0c61f55e6e  dpkg_1.14.5_i386.deb
$ sha1sum dpkg_1.14.5_i386.deb
38b69116a6d817c37400c9c5b4fc3eff241fa648  dpkg_1.14.5_i386.deb

Is this a known problem?

Javier

[1] Tested
http://ulises.hostalia.com/debian/pool/main/d/dpkg/dpkg_1.14.5_i386.deb
(the Debian Spanish mirror: ftp.es.debian.org)
and
http://ftp.debian.org/debian/pool/main/d/dpkg/dpkg_1.14.5_i386.deb



signature.asc
Description: Digital signature

Re: Please cleanup your home on gluck!

[Raphael Hertzog]

On Wed, 01 Aug 2007, Joerg Jaspert wrote:
> Hello DDs,
> 
> as gluck was running out of diskspace earlier today we would like to ask
> you to cleanup old files in your homedirectory on gluck. 

gluck == people.debian.org == cvs.debian.org 
(in case some are using only the aliased name)

At the same time, feel free to checkout your alioth account. Those who
still have a COSTA_home symlink pointing to the old costa.d.o data, might
check those files and remove them (we're not yet short on space, but
cleanup never hurts).

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 andASCII character encodings

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/01/07 02:02, Marc Haber wrote:
> On Wed, 01 Aug 2007 04:01:29 +0200, Antonio Diaz Diaz
> <[EMAIL PROTECTED]> wrote:
>> GNU Moe is a console text editor written to be stable, compact and 
>> powerful. It is the middle point between GNU Ed and GNU Emacs, and it 
>> deliberately doesn't support multibyte encodings.
> 
> The last sentence rules it out for me. I insist in being able to write
> comments in my native language.

Change your native language to American.  Problem solved!

> Including a new non-UTF8-capable editor in the archive in 2007 is the
> wrong signal, IMO.

If it can't be encoded in ANSI_X3.4-1968, it doesn't need to be encoded.



(For the humor impaired, or those who haven't yet drunk their
coffee: such chauvinistic rants are *OBVIOUSLY* designed as
sarcastic humor.  Angry repliers will be hereafter branded as
boorish sticks in the mud.)

- --
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGsGupS9HxQb37XmcRAi0wAJ0bR3LdINxq30H2SlaMREXe70FqjQCfbD48
uwOgsOjlI8iqlv5+ofk9mD8=
=xQVp
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Please cleanup your home on gluck!

[Joerg Jaspert]

Hello DDs,

as gluck was running out of diskspace earlier today we would like to ask
you to cleanup old files in your homedirectory on gluck. We already
pinged those using lots of space, so got a little bit freed up, but
every bit helps, so please remove whatever is old and unneeded - or can
easily be put elsewhere.

Thanks!

-- 
bye Joerg
Some NM:
>A developer contacts you and asks you to met for a keysign. What is
>your response and why?
Do you like beer? When do we meet? [...]


pgpd0sBhY471L.pgp
Description: PGP signature

Re: Prevent pdebuild from removing temporary build dir

[Paul Wise]

On 8/1/07, Pierre Habouzit <[EMAIL PROTECTED]> wrote:

> > Sounds like what I'm looking for but I have problems to implement this
> > hint.  I tried pdebuild --hookdir $HOME/.pbuilder and also added
> > HOOKDIR=/home/myhome/.pbuilder to my .pbuilderrc but there is no visible
> > effect.  Did I missed something?
>
>   it's used iff the build fails. So you have to make it fail...

There are other hooks that run at different times. I have B10shell,
C10shell, D10shell. I forget which one is which, but I get a shell
before installing deps, and after both failures and successes.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Prevent pdebuild from removing temporary build dir

[Pierre Habouzit]

On Wed, Aug 01, 2007 at 09:08:44AM +0200, Andreas Tille wrote:
> On Tue, 31 Jul 2007, Pierre Habouzit wrote:
> 
> >>How about using pbuilder hooks?  Something like $hookdir/C01_shell:
> >>
> >>--- 8< ---
> >>#!/bin/sh
> >>
> >>cd /tmp/buildd/*/debian/..
> >>/bin/sh < /dev/tty > /dev/tty
> >>--- 8< ---
> >
> > you may even want to have some usable env, and enhance it that way:
> >
> >   [artemis] cat .pbuilder/C10_launch_shell
> >   #!/bin/sh
> >   # invoke shell if build fails.
> >
> >   echo "I: installing necessary tools to work in the damn chroot"
> >   apt-get install -y --force-yes vim zsh &>/dev/null
> >   dpkg --purge nvi
> >
> >   cd /tmp/buildd/*/debian/..
> >
> >   /bin/zsh < /dev/tty > /dev/tty
> 
> Sounds like what I'm looking for but I have problems to implement this
> hint.  I tried pdebuild --hookdir $HOME/.pbuilder and also added
> HOOKDIR=/home/myhome/.pbuilder to my .pbuilderrc but there is no visible
> effect.  Did I missed something?

  it's used iff the build fails. So you have to make it fail...

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpgomCPj7saE.pgp
Description: PGP signature

Re: stupid dependencies on update-inetd

[Steve Langasek]

On Sun, Jul 29, 2007 at 12:42:02PM +0200, Marco d'Itri wrote:
> > The rationale for samba depending on update-inetd was that samba does *not*
> > depend on the availability of an inet superserver; it only depends on the
> > availability of the update-inetd interface, in order for its maintainer
> > scripts to run correctly.
> Again, the update-inetd interface is formally provided by
> inet-superserver and not by update-inetd.

So there's no allowance for a package that wants to interface with inetd if
it's installed, but doesn't depend on inetd being installed?

> > But I would still like input on the use of this dependency for samba; I
> > rather expect we would get complaints if samba depended on inet-superserver
> > when it doesn't use it in the default configuration.
> Do not depend on the presence of /usr/sbin/update-inetd then.

How should idempotent maintainer scripts that call update-inetd work
otherwise?  I'd rather not leave cruft around in /etc/inetd.conf as a
consequence of inet-superserver not being installed at the right moment.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 andASCII character encodings

[Marc Haber]

On Wed, 01 Aug 2007 04:01:29 +0200, Antonio Diaz Diaz
<[EMAIL PROTECTED]> wrote:
>GNU Moe is a console text editor written to be stable, compact and 
>powerful. It is the middle point between GNU Ed and GNU Emacs, and it 
>deliberately doesn't support multibyte encodings.

The last sentence rules it out for me. I insist in being able to write
comments in my native language.

Including a new non-UTF8-capable editor in the archive in 2007 is the
wrong signal, IMO.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Prevent pdebuild from removing temporary build dir

[Andreas Tille]

On Tue, 31 Jul 2007, Pierre Habouzit wrote:


How about using pbuilder hooks?  Something like $hookdir/C01_shell:

--- 8< ---
#!/bin/sh

cd /tmp/buildd/*/debian/..
/bin/sh < /dev/tty > /dev/tty
--- 8< ---


 you may even want to have some usable env, and enhance it that way:

   [artemis] cat .pbuilder/C10_launch_shell
   #!/bin/sh
   # invoke shell if build fails.

   echo "I: installing necessary tools to work in the damn chroot"
   apt-get install -y --force-yes vim zsh &>/dev/null
   dpkg --purge nvi

   cd /tmp/buildd/*/debian/..

   /bin/zsh < /dev/tty > /dev/tty


Sounds like what I'm looking for but I have problems to implement this
hint.  I tried pdebuild --hookdir $HOME/.pbuilder and also added
HOOKDIR=/home/myhome/.pbuilder to my .pbuilderrc but there is no visible
effect.  Did I missed something?

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]