Re: lilypond and python

[Loïc Minier]

On Wed, Jul 26, 2006, Martin Michlmayr wrote:
> You could just add an explicit dependency on python2.4 and do a
> s/python/python2.4/ over lilypond.

 For which I've sent a patch already.

-- 
Loïc Minier <[EMAIL PROTECTED]>


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

Re: lilypond and python

[Pierre Habouzit]

Le mer 26 juillet 2006 08:41, Thomas Bushnell BSG a écrit :
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> >> It takes about eight hours per compilation attempt on my available
> >> hardware running unstable.
> >
> > oh, and you really need to watch all the lines of the compilation
> > during the build ? lilypond seems like a real PITA to package
> > indeed !
>
> No, but it uses up the laptop while it's building, and forces me to,
> for example, stay in the same place.  It means that the cycle time on
> even minor errors can be obscenely long.

well, you know, I do help to maintain most of the KDE modules, so tell 
me about long testing cycles, I think it could be interesting.

and you know, you can use ccache, that speeds things a lot (on my 
machine it makes me compile most of kde modules in less than 15 minutes 
after the first full without ccache compilation).

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


pgpdJNsTATqXV.pgp
Description: PGP signature

Re: lilypond and python

[Loïc Minier]

On Tue, Jul 25, 2006, Thomas Bushnell BSG wrote:
> Some have suggested patching lilypond to call python2.4, depending on
> python2.4, and not bothering with python-central and pyversions and
> such.

 No, this is still required, but I didn't want to force a choice between
 python-support or python-central.

-- 
Loïc Minier <[EMAIL PROTECTED]>


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

Re: ITA: lcdproc

[Christoph Berg]

Re: José Luis Tallón 2006-07-25 <[EMAIL PROTECTED]>
> This is mostly to let ftpmasters know that he has indeed agreed to
> these terms so that the upload won't be rejected.
> Jon, just give an ACK on-list and that should be it.

Unless you are building new binaries, your upload won't be NEW anyway.
Even if it were, a note in debian/changelog would be enough.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: Bug#379475: [Etch] Should sysfsutils be added to the base system?

[Riku Voipio]

On Tue, Jul 25, 2006 at 06:10:23PM +0200, Eduard Bloch wrote:
> I disagree. You compare a 11kB utility (sysctl) with a new 132kB
> package.

You are comparing two completly different things. If we are to
actually compare the size of tools actually *needed*:

-rwxr-xr-x 1 root root 1554 2006-05-12 10:47 /etc/init.d/sysfsutils

vs

-rwxr-xr-x 1 root root 1244 2006-06-26 06:13 /etc/init.d/procps.sh
-rwxr-xr-x 1 root root 9288 2006-06-29 03:08 /sbin/sysctl
-rw-r--r-- 1 root root 48928 2006-06-29 03:08 /lib/libproc-3.2.7.so

If you had bothered to read /etc/init.d/sysfsutils before starting the
"bash the new and unknown" fest, you would see that it does not call 
systool and thus the package size or libsysfs2 size are not a problem.

If we break sysfsutils initscript to another package, we have less bloat 
than what sysctl brings. Actually /proc/sys could be handled with
the same script with trivial changes.


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

Re: Getting rid of circular dependencies, stage 5

[Goswin von Brederlow]

Ian Jackson <[EMAIL PROTECTED]> writes:

> Josselin Mouette writes ("Re: Getting rid of circular dependencies, stage 5"):
>> Le lundi 24 juillet 2006 à 17:15 +0100, Ian Jackson a écrit :
>> > Of course particular instances of circular dependencies might be
>> > problematic.  I would try to avoid it other than in closely coupled
>> > sets of packages, and it is best of one of the packages in the cycle
>> > is per data without a postinst.
>> 
>> This is entirely wrong. There have several been RC bugs (some that break
>> the buildds) caused by circular dependencies on closely coupled sets of
>> packages.
>
> ??
>
> I said `particular instances of circular dependencies might be
> problematic'.  Obviously circular dependencies might be wrong or
> broken.  Non-circular dependencies might be wrong or broken too.
>
> Package maintainers often put mad stuff in control files.
>
> Ian.

So you seem to be all for cleaning out that mad stuff, right?

Lets all get on with the list initialiy posted and fix those circular
depends or note why they are required.

MfG
Goswin


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

Re: Getting rid of circular dependencies, stage 5

[Goswin von Brederlow]

Joey Hess <[EMAIL PROTECTED]> writes:

> Josselin Mouette wrote:
>> Le dimanche 23 juillet 2006 à 10:55 -0400, Joey Hess a écrit :
>> > > Furthermore, there is no real justification for the circular dependency
>> > > in debconf. Why don't you just fix it?
>> > 
>> > <[EMAIL PROTECTED]>
>> > <[EMAIL PROTECTED]>

<[EMAIL PROTECTED]>:
> Henning Glawe wrote:
> > To illustrate the scenario:
> > - Package A depends on package B, which in turn depends on A
> >   0) User calls 'apt-get install  A B
> >  ':
> >   1) apt splits the whole list into smaller parts after sorting by 
> > dependency
> >  where, in case this bug occurs:
> >=" A"
> >="B "
> >   2) apt calls 'dpkg --unpack' for each element of  and 
> >  == so far no problem ==
> >   3) apt calls 'dpkg --configure ' and 'dpkg --configure '
> >  where the first step already fails, because B is not in
> >  , but A depends on B
> >  == complete failure, user has to recover manually: 
>
> debconf will not break in this situation
>
> (BTW, it's not formally essential, but it needs to have the same
> qualities as essential packages, and does.)

Debconf might not break in that situation but the system does. dpkg
still refuses to install the package without depends and
apt/aptitude/whatever fails. The user has to fix things up.
 
>> This doesn't answer the question. Let me rephrase it another way. If
>> someone provides a patch to remove that circular dependency, will you
>> apply it?
>
> Only if it managed to comprehend why the circular dependency is
> currently there and somehow address the issues it solves.

Then please enlighten us. There is little point of us stumbling in the
dark when you already have a perfectly good explanation why we will
fail.

MfG
Goswin


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

Re: Getting rid of circular dependencies, stage 5

[Ian Jackson]

Goswin von Brederlow writes ("Re: Getting rid of circular dependencies, stage 
5"):
> So you seem to be all for cleaning out that mad stuff, right?

Absolutely.

> Lets all get on with the list initialiy posted and fix those circular
> depends or note why they are required.

I agree that there are many silly dependencies and they should be
fixed.

But, for example,  foo <-Depends-> foo-data  is not usually an example
of a silly dependency.

I think you should try to remove entries from your list when they
follow that pattern (or others where we know that it makes sense).

Ian.


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

Re: Self-conflicts and self-depends

[Fabio Tranchitella]

Il giorno mar, 25/07/2006 alle 18.10 -0700, Russ Allbery ha scritto:
> So, are people sure this is not useful even if the package name doubles as
> a virtual package?  It seems to me like it would be.  Or are people just
> arguing that that case will never occur?

Conflicts on virtual packages assure that two real packages providing
the virtual one can't be installed togheter, so let's say:

A: provides D; conflicts D
B: provides D; conflicts D

It is not possible to install both pkg A and pkg B because both provide
pkg D and the other package conflicts with it. If we replace D with A,
and remove the self-conflicts/self-provides, the situation would be:

A: nothing;
B: provides A; conflicts A

... which produces the same result, because you can't install both A and
B because B conflicts with (the real package) A.

For me, self-conflicts make no sense in every situation.

-- 
Fabio Tranchitella <[EMAIL PROTECTED]>.''`.
Proud Debian GNU/Linux developer, admin and user.: :'  :
 `. `'`
   http://people.debian.org/~kobold/   `-
_
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564


signature.asc
Description: Questa è una parte del messaggio	firmata digitalmente

Re: New Naming Convention

[Michael Banck]

On Tue, Jul 25, 2006 at 10:22:44AM -0700, Jeremy Herndon wrote:
> I currently do not subscribe to the mailing lists. So I don't know if
> this has been considered. 

This is not a development issue, and should not be discussed on this
list (which has enough traffic already) considering the high
bike-shedding potential of the discussion.


thanks for considering,

Michael


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

Re: Getting rid of circular dependencies, stage 5

[Andreas Barth]

Hi,

* Ian Jackson ([EMAIL PROTECTED]) [060726 13:18]:
> But, for example,  foo <-Depends-> foo-data  is not usually an example
> of a silly dependency.

Actually, there is no reason why foo-data needs foo configured before
being configured, but there might be reason for the other direction.
Why not inventing some new "Depends-for-being-useful" from foo-data to
foo, and having Depends cycle-free?


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Getting rid of circular dependencies, stage 5

[Stephen Gran]

This one time, at band camp, Andreas Barth said:
> Hi,
> 
> * Ian Jackson ([EMAIL PROTECTED]) [060726 13:18]:
> > But, for example,  foo <-Depends-> foo-data  is not usually an example
> > of a silly dependency.
> 
> Actually, there is no reason why foo-data needs foo configured before
> being configured, but there might be reason for the other direction.
> Why not inventing some new "Depends-for-being-useful" from foo-data to
> foo, and having Depends cycle-free?

Like, say, Enhances: ?

I always thought that basically meant "useless by myself, but is useful
for foo".  Pity it never got implemented into anything much.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Getting rid of circular dependencies, stage 5

[Andreas Barth]

* Stephen Gran ([EMAIL PROTECTED]) [060726 13:46]:
> This one time, at band camp, Andreas Barth said:
> > Hi,
> > 
> > * Ian Jackson ([EMAIL PROTECTED]) [060726 13:18]:
> > > But, for example,  foo <-Depends-> foo-data  is not usually an example
> > > of a silly dependency.
> > 
> > Actually, there is no reason why foo-data needs foo configured before
> > being configured, but there might be reason for the other direction.
> > Why not inventing some new "Depends-for-being-useful" from foo-data to
> > foo, and having Depends cycle-free?
> 
> Like, say, Enhances: ?
> 
> I always thought that basically meant "useless by myself, but is useful
> for foo".  Pity it never got implemented into anything much.

Enhances is the reverse of Suggests.

We have (I'm now using needs, though this is perhaps not the perfect
word for the new dependency):
(A (op) B)   means:
Pre-Depends  B configured before A being unpackaged
Depends  B configured before A being configured
NeedsB configured before A being used

Basically, that would give us a new package status, pending (or so). If
we have A -> B (Needs), that would change the installation from:
{pre-depends satisfied} -> [pre-instA] -> [unpacking A] -> unpackaged ->
  [configuring A] -> installed
to
{pre-depends satisfied} -> [pre-instA] -> [unpacking A] -> unpackaged ->
  [configuring A] -> pending -> {all Needs satisfied} -> installed


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Getting rid of circular dependencies, stage 5

[Frank Küster]

Andreas Barth <[EMAIL PROTECTED]> wrote:

> Hi,
>
> * Ian Jackson ([EMAIL PROTECTED]) [060726 13:18]:
>> But, for example,  foo <-Depends-> foo-data  is not usually an example
>> of a silly dependency.
>
> Actually, there is no reason why foo-data needs foo configured before
> being configured, but there might be reason for the other direction.
> Why not inventing some new "Depends-for-being-useful" from foo-data to
> foo, and having Depends cycle-free?

What about using Suggests instead of "Depends-for-being-useful"?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Status of iproute package for Etch

[Milan P. Stanic]

Hi,

[ I thought to post that message to Alexander Wirt but I don't like
  to send private mail to people before previous agreement ]

Default kernel in Etch will be 2.6.17 but the iproute package for now
is 20051007 version.

For new kernels there are new upstream releases at:
http://developer.osdl.org/dev/iproute2/download/ and they are named as
iproute2-kernel.version-releasedate

I made deb package of iproute2-2.6.15-060110 with some patches which
Stex (aka Stefano Melchior <[EMAIL PROTECTED]> ) made for
some older version of iproute2. It works but I'm not sure if it is
lintian clean. I'm ready to help as much as I can to move on.

What should be done to got new version of iproute in Etch?
Alexander?



signature.asc
Description: Digital signature

Re: Getting rid of circular dependencies, stage 5

[Andreas Barth]

* Frank Küster ([EMAIL PROTECTED]) [060726 14:49]:
> What about using Suggests instead of "Depends-for-being-useful"?

Suggests is *way* weaker. The Needs would trigger automatic installation
with any tool. Actually, if
A->B (depends), B->C(depends), and C->B(Needs), then A won't be
configured until both B and C are installed.

Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Getting rid of circular dependencies, stage 5

[Simon Richter]

Hi,

Andreas Barth wrote:

> Suggests is *way* weaker. The Needs would trigger automatic installation
> with any tool. Actually, if
> A->B (depends), B->C(depends), and C->B(Needs), then A won't be
> configured until both B and C are installed.

What stops us from using Recommends for that. The definition for
Recommends used to be "you may not install these, but you should have a
reason for it", which is exactly the foo/foo-data case.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Getting rid of circular dependencies, stage 5

[Andreas Barth]

* Simon Richter ([EMAIL PROTECTED]) [060726 15:38]:
> Andreas Barth wrote:
> 
> > Suggests is *way* weaker. The Needs would trigger automatic installation
> > with any tool. Actually, if
> > A->B (depends), B->C(depends), and C->B(Needs), then A won't be
> > configured until both B and C are installed.
> 
> What stops us from using Recommends for that. The definition for
> Recommends used to be "you may not install these, but you should have a
> reason for it", which is exactly the foo/foo-data case.

actually, Recommends are still weaker. I personally see a gap between
Depends and Recommends, which is Needs. If I'm the only one, it's ok. If
other people see the same gap, we might want to fix it. :)


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Getting rid of circular dependencies, stage 5

[Frank Küster]

Andreas Barth <[EMAIL PROTECTED]> wrote:

> * Frank Küster ([EMAIL PROTECTED]) [060726 14:49]:
>> What about using Suggests instead of "Depends-for-being-useful"?
>
> Suggests is *way* weaker. 

Sorry, I meant Recommends.

> The Needs would trigger automatic installation
> with any tool. Actually, if
> A->B (depends), B->C(depends), and C->B(Needs), then A won't be
> configured until both B and C are installed.

That's a clever idea.  However, so far nobody has provided any
information where this would be actually needed, except a general
"people might install foo-data and wonder why no program foo is
provided" or a "the knowing already know".  Is it really worth the
effort? 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Self-conflicts and self-depends

[Hamish Moffatt]

On Wed, Jul 26, 2006 at 01:17:30PM +0200, Fabio Tranchitella wrote:
> Il giorno mar, 25/07/2006 alle 18.10 -0700, Russ Allbery ha scritto:
> > So, are people sure this is not useful even if the package name doubles as
> > a virtual package?  It seems to me like it would be.  Or are people just
> > arguing that that case will never occur?
> 
> Conflicts on virtual packages assure that two real packages providing
> the virtual one can't be installed togheter, so let's say:
> 
> A: provides D; conflicts D
> B: provides D; conflicts D
> 
> It is not possible to install both pkg A and pkg B because both provide
> pkg D and the other package conflicts with it. If we replace D with A,
> and remove the self-conflicts/self-provides, the situation would be:
> 
> A: nothing;
> B: provides A; conflicts A
> 
> ... which produces the same result, because you can't install both A and
> B because B conflicts with (the real package) A.
> 
> For me, self-conflicts make no sense in every situation.

Now extend for more than two packages. Should each package list every
other, require every package to be updated when another is added?

Instead they can all provide and conflict a common virtual package.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Getting rid of circular dependencies, stage 5

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> Hi,
>
> * Ian Jackson ([EMAIL PROTECTED]) [060726 13:18]:
>> But, for example,  foo <-Depends-> foo-data  is not usually an example
>> of a silly dependency.
>
> Actually, there is no reason why foo-data needs foo configured before
> being configured, but there might be reason for the other direction.
> Why not inventing some new "Depends-for-being-useful" from foo-data to
> foo, and having Depends cycle-free?
>
>
> Cheers,
> Andi

We have:

Pre-Depends: Needs to be unpacked and configure before me
Depends: Needs to be configured before me

How about adding:

Post-Depends: Needs to be configured for me to be useable

The difference between Depends and Post-Depends would be that only the
former may use the other package in the maintainer scripts.


To implement this dpkg would need a new state. One between
unconfigured and installed, say post-config or configured. Packages
would go from purged to unpacked (unpacking done) to configured
(maintainer scripts have been run) to installed (Post-Depends have
been configured).

Post-Depends cycles could be broken by allowing: A package can go from
configured to installed when all its Post-Depends are configured or
installed. Or Post-Depends cycles are just required to be transitioned
as one, no splitting by apt-get into multiple calls allowed.

MfG
Goswin


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

Re: Getting rid of circular dependencies, stage 5

[Goswin von Brederlow]

Frank Küster <[EMAIL PROTECTED]> writes:

> Andreas Barth <[EMAIL PROTECTED]> wrote:
>
>> * Frank Küster ([EMAIL PROTECTED]) [060726 14:49]:
>>> What about using Suggests instead of "Depends-for-being-useful"?
>>
>> Suggests is *way* weaker. 
>
> Sorry, I meant Recommends.
>
>> The Needs would trigger automatic installation
>> with any tool. Actually, if
>> A->B (depends), B->C(depends), and C->B(Needs), then A won't be
>> configured until both B and C are installed.
>
> That's a clever idea.  However, so far nobody has provided any
> information where this would be actually needed, except a general
> "people might install foo-data and wonder why no program foo is
> provided" or a "the knowing already know".  Is it really worth the
> effort? 
>
> Regards, Frank

Joey said debconf requires it circular dependency.

I hope everyone agrees that foo -> foo-data is required but foo-data
-> foo generaly isn't. Only reason for the reverse way generaly is to
force installation of foo when someone stupid install foo-data only
and purging of foo-data when foo is removed. If depends is the right
thing for fixing stupidiy or cleanup problems is another discussion so
lets ignore those cases.


MfG
Goswin


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

Re: Self-conflicts and self-depends

[Goswin von Brederlow]

Fabio Tranchitella <[EMAIL PROTECTED]> writes:

> Il giorno mar, 25/07/2006 alle 18.10 -0700, Russ Allbery ha scritto:
>> So, are people sure this is not useful even if the package name doubles as
>> a virtual package?  It seems to me like it would be.  Or are people just
>> arguing that that case will never occur?
>
> Conflicts on virtual packages assure that two real packages providing
> the virtual one can't be installed togheter, so let's say:
>
> A: provides D; conflicts D
> B: provides D; conflicts D
>
> It is not possible to install both pkg A and pkg B because both provide
> pkg D and the other package conflicts with it. If we replace D with A,
> and remove the self-conflicts/self-provides, the situation would be:
>
> A: nothing;
> B: provides A; conflicts A
>
> ... which produces the same result, because you can't install both A and
> B because B conflicts with (the real package) A.
>
> For me, self-conflicts make no sense in every situation.

Say your "A" package gets renamed to (or is named) "D". "D" then still
has to conflict "D" so "B" can't be installed in
parallel. exim4-config is an example of such a case.

MfG
Goswin


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

Re: New Naming Convention

[Miriam Ruiz]

 --- Adrian von Bidder <[EMAIL PROTECTED]> escribió:

> (Hmmm.  Model/Actress names are now available for use, now that the scripts 
> have been renamed.  Yay Debian Noemi 4.1!)

I don't want to start a flame, but I think this was out of place.

Miry




__ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com


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

Re: Self-conflicts and self-depends

[Fabio Tranchitella]

Il giorno mer, 26/07/2006 alle 16.48 +0200, Goswin von Brederlow ha
scritto:
> > Conflicts on virtual packages assure that two real packages providing
> > the virtual one can't be installed togheter, so let's say:
> >
> > A: provides D; conflicts D
> > B: provides D; conflicts D
> >
> > It is not possible to install both pkg A and pkg B because both provide
> > pkg D and the other package conflicts with it. If we replace D with A,
> > and remove the self-conflicts/self-provides, the situation would be:
> >
> > A: nothing;
> > B: provides A; conflicts A
> >
> > ... which produces the same result, because you can't install both A and
> > B because B conflicts with (the real package) A.
> >
> > For me, self-conflicts make no sense in every situation.
> 
> Say your "A" package gets renamed to (or is named) "D". "D" then still
> has to conflict "D" so "B" can't be installed in
> parallel. exim4-config is an example of such a case.

I don't understand if you talk about my first example or about the
second one. 

If it is the first, then D doesn't need to conflict on itself: it won't
be installable because "B" already conflicts with it. 

I don't see neither why exim4-config is an example of such a case: there
are no packages in the archive which provides exim4-config, and even if
they would exists, they would conflict with exim4-config so they won't
be installable in parallel.

The conflict work also if just one of the two involved packages declares
the conflict, or not?

Cheers,

-- 
Fabio Tranchitella <[EMAIL PROTECTED]>.''`.
Proud Debian GNU/Linux developer, admin and user.: :'  :
 `. `'`
   http://people.debian.org/~kobold/   `-
_
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564


signature.asc
Description: Questa è una parte del messaggio	firmata digitalmente

Re: Getting rid of circular dependencies, stage 5

[Josselin Mouette]

Le mercredi 26 juillet 2006 à 11:49 +0100, Ian Jackson a écrit :
> I agree that there are many silly dependencies and they should be
> fixed.

And don't you agree that there have been enough unpredictable bug cases
caused by circular dependencies so that we can try remove all of
unneeded ones? We don't want unpredictable things to happen, and
circular dependencies are a very good way to make things unpredictable.
In the general case, I want bugs to be reproducible.

> But, for example,  foo <-Depends-> foo-data  is not usually an example
> of a silly dependency.

It is. It is useless, as foo-data should only recommend foo. And it is
dangerous. For example, when removing these packages, dpkg gets lost and
may remove one of them before a reverse-dependency of the other one. And
I think it is way simpler to get rid of a useless dependency than fixing
dpkg to handle such cases (which anyway can NOT be done in a predictable
way).

> I think you should try to remove entries from your list when they
> follow that pattern (or others where we know that it makes sense).

These are the easiest ones to fix, so there is no excuse to fix them.
And I have yet to see a circular dependency that makes sense.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: Bug#379475: [Etch] Should sysfsutils be added to the base system?

[Eduard Bloch]

#include 
* Riku Voipio [Wed, Jul 26 2006, 12:18:54PM]:
> On Tue, Jul 25, 2006 at 06:10:23PM +0200, Eduard Bloch wrote:
> > I disagree. You compare a 11kB utility (sysctl) with a new 132kB
> > package.
> 
> You are comparing two completly different things. If we are to
> actually compare the size of tools actually *needed*:
> 
> -rwxr-xr-x 1 root root 1554 2006-05-12 10:47 /etc/init.d/sysfsutils

The initial bug report was not clear about was is actually wished. If
that is only about some init.d code, that should be merged with procfs
then, IMO.

Eduard.
-- 
 *prust*
 #, fuzzy
 msgid "Failed"
 msgstr "Weiblich"


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

Re: Self-conflicts and self-depends

[Fabio Tranchitella]

Il giorno gio, 27/07/2006 alle 00.22 +1000, Hamish Moffatt ha scritto:
> Now extend for more than two packages. Should each package list every
> other, require every package to be updated when another is added?
> 
> Instead they can all provide and conflict a common virtual package.

It is ok to conflict on a common virtual package, but I don't see the
point for a package conflicting with itself. If there are other packages
which provide it, then it's up to them to conflict with the real one and
we are not talking about **virtual** packages anymore.

Another example:

 * foo
 * foo-extended: provides foo, conflicts foo;
 * foo-extended-nosql: provides foo, conflicts foo;

Is it really needed for foo to conflict with itself to have foo-extended
or foo-extended-nosql uninstallable in parallel with it? Aren't their
conflicts enough?

-- 
Fabio Tranchitella <[EMAIL PROTECTED]>.''`.
Proud Debian GNU/Linux developer, admin and user.: :'  :
 `. `'`
   http://people.debian.org/~kobold/   `-
_
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564


signature.asc
Description: Questa è una parte del messaggio	firmata digitalmente

Re: Getting rid of circular dependencies, stage 5

[Frank Küster]

Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> Frank Küster <[EMAIL PROTECTED]> writes:
>
>> Andreas Barth <[EMAIL PROTECTED]> wrote:
>>
>>> * Frank Küster ([EMAIL PROTECTED]) [060726 14:49]:
 What about using Suggests instead of "Depends-for-being-useful"?
>>>
>>> Suggests is *way* weaker. 
>>
>> Sorry, I meant Recommends.
>>
>>> The Needs would trigger automatic installation
>>> with any tool. Actually, if
>>> A->B (depends), B->C(depends), and C->B(Needs), then A won't be
>>> configured until both B and C are installed.
>>
>> That's a clever idea.  However, so far nobody has provided any
>> information where this would be actually needed, except a general
>> "people might install foo-data and wonder why no program foo is
>> provided" or a "the knowing already know".  Is it really worth the
>> effort? 
>>
>> Regards, Frank
>
> Joey said debconf requires it circular dependency.

Yes, that's what I meant with "the knowing already know".  He asserted
that, but he did not yet tell us why, or where we could read why. 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Self-conflicts and self-depends

[Hubert Chan]

On Thu, 27 Jul 2006 00:22:54 +1000, Hamish Moffatt <[EMAIL PROTECTED]> said:

> On Wed, Jul 26, 2006 at 01:17:30PM +0200, Fabio Tranchitella wrote:
>> A: nothing;
>> B: provides A; conflicts A
>> 
>> ... which produces the same result, because you can't install both A
>> and B because B conflicts with (the real package) A.
>> 
>> For me, self-conflicts make no sense in every situation.

> Now extend for more than two packages. Should each package list every
> other, require every package to be updated when another is added?

A: nothing;
B: provides A; conflicts A
C: provides A; conflicts A
D: provides A; conflicts A
E: provides A; conflicts A
F: provides A; conflicts A
 .
 .
 .

> Instead they can all provide and conflict a common virtual package.

Or, yes, they can do that.  (In fact, the above is basically the same
thing, except that package A happens to be named the same as the virtual
package.)  But this doesn't give any reason for why package A needs to
conflict with itself.

-- 
Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA   (Key available at wwwkeys.pgp.net)
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


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

Re: lilypond and python

[Thomas Bushnell BSG]

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

> On Tue, Jul 25, 2006, Thomas Bushnell BSG wrote:
>> Some have suggested patching lilypond to call python2.4, depending on
>> python2.4, and not bothering with python-central and pyversions and
>> such.
>
>  No, this is still required, but I didn't want to force a choice between
>  python-support or python-central.

It is very confusing to me why lilypond should need either
python-support or python-central at all.  Can you explain?

Re: lilypond and python

[Thomas Bushnell BSG]

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

> On Wed, Jul 26, 2006, Martin Michlmayr wrote:
>> You could just add an explicit dependency on python2.4 and do a
>> s/python/python2.4/ over lilypond.
>
>  For which I've sent a patch already.

I believe the patch you sent was not against the current upstream
release, unless you are referring to something different.

Bug#379984: O: grip -- GNOME-based CD-player/ripper/encoder

[Taku YASUI]

Package: wnpp
Severity: normal

Grip has been reported lots of bugs.  However I haven't make
a enough time to follow and maintain.

The package description is as follows:

 It has the ripping capabilities of cdparanoia builtin, but can also
 use external rippers (such as cdda2wav). It also provides an
 automated frontend for MP3 encoders, letting you take a disc and
 transform it easily straight into MP3s. The CDDB protocol is
 supported for retrieving track information from disc database
 servers. Grip works with DigitalDJ to provide a unified
 "computerized" version of your music collection.


pgpKZELI3UXP6.pgp
Description: PGP signature

Re: Self-conflicts and self-depends

[Russ Allbery]

Fabio Tranchitella <[EMAIL PROTECTED]> writes:
> Il giorno mar, 25/07/2006 alle 18.10 -0700, Russ Allbery ha scritto:

>> So, are people sure this is not useful even if the package name doubles
>> as a virtual package?  It seems to me like it would be.  Or are people
>> just arguing that that case will never occur?

> Conflicts on virtual packages assure that two real packages providing
> the virtual one can't be installed togheter, so let's say:

> A: provides D; conflicts D
> B: provides D; conflicts D

> It is not possible to install both pkg A and pkg B because both provide
> pkg D and the other package conflicts with it.

Right.

> If we replace D with A, and remove the self-conflicts/self-provides, the
> situation would be:

> A: nothing;
> B: provides A; conflicts A

> ... which produces the same result, because you can't install both A and
> B because B conflicts with (the real package) A.

Okay, I can see how that works.

However, I don't see how the self-conflicts *hurts* anything, and some
people are currently using this technique, probably because it's easier to
remember to always have the Conflits.  So what are we gaining by adding a
check for this and making people change it?  Is there a problem here that
we're solving?  (Like, for instance, is this making dpkg or other package
tools more complicated in ways that getting rid of it would let us fix?)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Self-conflicts and self-depends

[Fabio Tranchitella]

On mer, 26 lug 2006, Russ Allbery wrote:
> However, I don't see how the self-conflicts *hurts* anything, and some
> people are currently using this technique, probably because it's easier to
> remember to always have the Conflits.  So what are we gaining by adding a
> check for this and making people change it?  Is there a problem here that
> we're solving?  (Like, for instance, is this making dpkg or other package
> tools more complicated in ways that getting rid of it would let us fix?)

Yes, is making my life harder dealing with conflicts in britney.
Oh, nothing that we can't skip with an if block, but you asked. :)

Cheers,

-- 
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http://www.tranchitella.it
_
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564


signature.asc
Description: Digital signature

Re: intent to hijack python-paramiko

[Jeremy Bouse]

Go ahead and NMU with my thanks and blessing... I've made my move cross-country but my system at home is still without network connectivity at this time and the telco has been unable to give me anything close to a firm ETA of when they will.
Regards,JeremyOn 7/17/06, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
* Wouter van Heyst <[EMAIL PROTECTED]> [2006-07-17 20:35]:> > He was moving cross-country in May, so I suggest you NMU for now.>> Would NMUing a new upstream be ok in this instance then?
I think so, yes.--Martin Michlmayrhttp://www.cyrius.com/

Re: lilypond and python

[Wouter Verhelst]

On Tue, Jul 25, 2006 at 07:25:59PM -0700, Thomas Bushnell BSG wrote:
> Adeodato Simó <[EMAIL PROTECTED]> writes:
> >   - From http://lists.debian.org/debian-devel/2006/07/msg00684.html:
> > > But I don't alas, have the time to spend on a workaround patch myself,
> > > which will (supposedly) become obselete very quickly.
> > The sad conclusion that, with this sentence being probably true (why
> > doubt your knowledge about your own time constraints), that preparing
> > such upload, given your skills _and_ hardware constraints, would
> > take you more time that writing all the amounts of text you've send
> > to this list during the last months about this very same issue, and
> > reading all replies herein.
> 
> This is incorrect; I write and read very quickly.

Oh, come on.

sed -i -e '1s/python[0-9\.]*/python2.4/' $(find . -name '*.py')

Don't tell me it takes you more than half a minute to come up with
something like that. And don't tell me you can write a mail such as the
one I'm replying to in less than half a second.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Bug#379857: ITP: git-completion -- content addressable filesystem (bash completion)

[Moritz Muehlenhoff]

Sebastian Harl wrote:
> * Package name: git-completion
>   Version : 0+20060722
>   Upstream Author : Ben Clifford <[EMAIL PROTECTED]>
> * URL : http://www.hawaga.org.uk/ben/tech/gitcompletion/
> * License : GPL
>   Description : content addressable filesystem (bash completion)
>
> git is a stupid (but extremely fast) directory content manager. It doesn't do 
> a whole lot, but what it 'does' do is track directory contents efficiently.
> .
> This package contains the bash completion for git, cogito and stg.

Why should this be a separate package? Either include it in the bash package
or into the /etc/bash_completion.d of git, cogito and stg.

Cheers,
Moritz


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

Re: Status of iproute package for Etch

[Florian Weimer]

* Milan P. Stanic:

> For new kernels there are new upstream releases at:
> http://developer.osdl.org/dev/iproute2/download/ and they are named as
> iproute2-kernel.version-releasedate

Do the newer versions include documentation of the semantics of the ip
commands (and not just the syntax)?


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

Re: Status of iproute package for Etch

[Milan P. Stanic]

On Wed, Jul 26, 2006 at 10:05:57PM +0200, Florian Weimer wrote:
> Do the newer versions include documentation of the semantics of the ip
> commands (and not just the syntax)?

I'm not sure if I understand you, but there are some documents which
describes ip command and some other programs (which comes with iproute
like ss and nstat) in package.

And there is nice howto about iproute and policy routing at
http://www.policyrouting.org/iproute2.doc.html which is not included
in iproute package but I hope it could.

Of course, there is also a famous LARTC HOWTO at http://lartc.org/howto/


signature.asc
Description: Digital signature

Re: Getting rid of circular dependencies, stage 5

[Adam Borowski]

On Wed, Jul 26, 2006 at 04:41:37PM +0200, Goswin von Brederlow wrote:
> Andreas Barth <[EMAIL PROTECTED]> writes:
> > * Ian Jackson ([EMAIL PROTECTED]) [060726 13:18]:
> >> But, for example,  foo <-Depends-> foo-data  is not usually an example
> >> of a silly dependency.
> >
> > Actually, there is no reason why foo-data needs foo configured before
> > being configured, but there might be reason for the other direction.
> > Why not inventing some new "Depends-for-being-useful" from foo-data to
> > foo, and having Depends cycle-free?
> 
> Pre-Depends: Needs to be unpacked and configure before me
> Depends: Needs to be configured before me
> 
> How about adding:
> 
> Post-Depends: Needs to be configured for me to be useable
> 
> The difference between Depends and Post-Depends would be that only the
> former may use the other package in the maintainer scripts.
> 
> 
> To implement this dpkg would need a new state. One between
> unconfigured and installed, say post-config or configured. Packages
> would go from purged to unpacked (unpacking done) to configured
> (maintainer scripts have been run) to installed (Post-Depends have
> been configured).

Adding a new state would break a lot of tools, and require a couple
of releases until it's functional.

What about this:
"Post-Depends:"/"Needs:" don't have to be satisfied for a package to
be configured.  If A "Needs:" B, you can still have A installed
without B, and have a perfectly functional system -- from dpkg's
point of view.
Apt and the frontends which understand the new field will scream at
you, and won't allow such a case to happen (unless forced).

If you have a mixed system where some tools know about the new field
and some which don't, you may end up with left-over cruft like
foo-data installed without foo.  This is not a problem except for
some disk space wasted -- you do have useless files on your
filesystem, but they have otherwise no detrimental effect.


This way, you could have this in for Etch.


Here's how existing tools handle the field:

dpkg-gencontrol: warning: unknown information field `C Needs' in
input data in general section of control info file
(and the field gets weeded out of the .deb)

dpkg -- no problems -- ignores it but stores

apt -- no problems (ignores it)

So, even backports would be covered with an acceptable failure mode.


> Post-Depends cycles could be broken by allowing: A package can go from
> configured to installed when all its Post-Depends are configured or
> installed. Or Post-Depends cycles are just required to be transitioned
> as one, no splitting by apt-get into multiple calls allowed.
In my proposal, apt wouldn't require to pass this to dpkg in any
special way.  It would just install B whenever A is selected for
installing, and remove A if you ask for removing B, without dpkg
knowing why this is done.

Cheers and schtuff,
-- 
1KB // Q: How do you spot a good inetd?
// A: It build-depends on equivs.


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

Re: Getting rid of circular dependencies, stage 5

[Bruce Sass]

On Tue July 25 2006 05:38, Goswin von Brederlow wrote:
> Except that libapt does NOT correctly handle dependency loops and can
> split them between dpkg calls causing install failures.
>
> The more circular depends there are the more likely such a failure
> becomes. So wouldn't it be a good thing to remove all the circular
> depends that are not neccessary?

Sure, but an even better thing would be to fix libapt.

It sounds pretty arbitrary of libapt to split an install into batches
based simply on size (assuming all the pre-depends, etc. have been
looked after), and it is just plain not right to place arbitrary
limits on the package archive because of failings in client software.

If that is the root of the problem with circular dependencies, and it 
has been known for years, why haven't any of the obvious fixes[1] been 
implemented?


- Bruce

[1] "obvious" fixes, imo:

- Heuristically remove potentially problematic packages from the batch.
  Eventually, either the afflicted packages will end up in the same
  batch or the last batch will be larger than what libapt wants to
  pass onto dpkg (the outcome of which is either the status quo or
  no-problem, depending mostly on how conservative the max size is on
  the target system.) The upside of this is that it is likely to be easy
  to implement as a filter function; the downside is that its
  inefficiency is magnified by the likelyhood of additional dpkg
  invocations.

- Build chunks based on the structure of the dependency tree of the
  packages being installed. E.g., the first batch sent to dpkg would
  consist of independent packages (which only depend on stuff already
  installed) depended upon by multiple packages, next would come chunks
  of packages with dependency relationships, finally the independent
  packages which couldn't be used to fill up prior batches. The upside
  is that it would be a very interesting (as in fun) project [recursion,
  graphs, packing, accommodating multiple chunk'n'batch strategies
  (because it is unlikely the same one would work "best" for daily
  upgrades from unstable -> yearly dist upgrades of stable)], maybe a
  DB, what more could a programmer want, eh]; the downside is that it
  may also be interesting in a "Chineses curse" kinda way
  [see: http://www.noblenet.org/reference/inter.htm].


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

Re: Bug#379857: ITP: git-completion -- content addressable filesystem (bash completion)

[Sebastian Harl]

Hi,

> > * Package name: git-completion
> >   Version : 0+20060722
> >   Upstream Author : Ben Clifford <[EMAIL PROTECTED]>
> > * URL : http://www.hawaga.org.uk/ben/tech/gitcompletion/
> > * License : GPL
> >   Description : content addressable filesystem (bash completion)
> >
> > git is a stupid (but extremely fast) directory content manager. It doesn't 
> > do 
> > a whole lot, but what it 'does' do is track directory contents efficiently.
> > .
> > This package contains the bash completion for git, cogito and stg.
> 
> Why should this be a separate package? Either include it in the bash package
> or into the /etc/bash_completion.d of git, cogito and stg.

Well, why shouldn't it be a separate package? It _is_ a separate source
package that's developed independently of anything git or bash related. Imho
it just would not make much sense to include it in any other package.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Re: Getting rid of circular dependencies, stage 5

[Joey Hess]

Bruce Sass wrote:
> [1] "obvious" fixes, imo:

- Use dpkg --command-fd

-- 
see shy jo


signature.asc
Description: Digital signature

Re: lilypond and python

[Stephen Gran]

This one time, at band camp, Wouter Verhelst said:
> On Tue, Jul 25, 2006 at 07:25:59PM -0700, Thomas Bushnell BSG wrote:
> > This is incorrect; I write and read very quickly.
> 
> Oh, come on.
> 
> sed -i -e '1s/python[0-9\.]*/python2.4/' $(find . -name '*.py')
> 
> Don't tell me it takes you more than half a minute to come up with
> something like that. And don't tell me you can write a mail such as the
> one I'm replying to in less than half a second.

What is this, solution number 4 for Mr. BSG's complaints?  I am almost
beginning to believe that he is more interested in complaining than just
fixing the problem.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: lilypond and python

[Thomas Bushnell BSG]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> Oh, come on.
>
> sed -i -e '1s/python[0-9\.]*/python2.4/' $(find . -name '*.py')
>
> Don't tell me it takes you more than half a minute to come up with
> something like that. And don't tell me you can write a mail such as the
> one I'm replying to in less than half a second.

Does it occur to you that this just may not be sufficient?  That just
perhaps there is more to it than that?  That I may have already
*tried* that, and the consistent insistences from others that it will
surely be sufficient indicate only that they have not *tried* it
themselves.

Thomas


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

Re: lilypond and python

[Thomas Bushnell BSG]

Stephen Gran <[EMAIL PROTECTED]> writes:

> What is this, solution number 4 for Mr. BSG's complaints?  I am almost
> beginning to believe that he is more interested in complaining than just
> fixing the problem.

Solution?  How about this, if I apply that recipe and try to compile,
you pay me $100 bucks if it doesn't work out of the box.


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

Re: lilypond and python

[Thomas Bushnell BSG]

Stephen Gran <[EMAIL PROTECTED]> writes:

> What is this, solution number 4 for Mr. BSG's complaints?  I am almost
> beginning to believe that he is more interested in complaining than just
> fixing the problem.

And the gratuitous rudeness is apalling.


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

Bug#206187: probably you

[Winifred]

Hi there lovely,
I was searching the net few days ago. I am new to this thing.
b
and saw your profile. I decided to email you cause I found 
you attractive. I might come down taob your cibty in few weeks.
Let me know if we can meet each other in person.b
I am attractive bgbirl. I am sure yaou won't regret it.
Reply to my personal email at [EMAIL PROTECTED]




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