Hi Mika!

On 03/03/2009 12:17 AM, Michael Prokop wrote:
> 
> I guess base64 1.5-2 provides what you wanted to get. :)
> I'm closing this bugreport therefor, feel free to re-open it if you
> encounter any problems!

Nice! That's the solution I was looking for (but which I was not able
to find yesterday).

Greetings,
 - Darsha

Hi Darsha!

I guess base64 1.5-2 provides what you wanted to get. :)
I'm closing this bugreport therefor, feel free to re-open it if you encounter 
any problems!

thx && regards,
-mika-

We believe that your issue has been closed by the upload of
Version 1.5-2 of base64 from Michael Prokop <mika@grml.org>.
The explanation is attached below

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 02 Mar 2009 21:58:31 +0100
Source: base64
Binary: base64
Architecture: source i386
Version: 1.5-2
Distribution: unstable
Urgency: low
Maintainer: Michael Prokop <mika@grml.org>
Changed-By: Michael Prokop <mika@grml.org>
Description: 
 base64     - dummy package - replaced by coreutils
Changes: 
 base64 (1.5-2) unstable; urgency=low
 .
   * Make this package a dummy package. This package is deprecated
     as coreutilsprovide base64 since version 6.0-1 nowadays.
     (Thanks to Rhonda for the idea regarding the dummy package,
      thanks to Darsha for the bugreport!) [Closes: issue645]
Checksums-Sha1: 
 7f235eee25392bebac3d93c9c597e35933388116 1052 base64_1.5-2.dsc
 2f83c0a81606ea41283b814ee5196ca03e8ef3c3 24411 base64_1.5-2.diff.gz
 f1a38bb006a3be45982e5fb6767ab1b4e77c09d3 1938 base64_1.5-2_i386.deb
Checksums-Sha256: 
 40fe03607bda3c9fe00212c98a93879568b2ba71f2e914f3d3e2b47b3c413804 1052 base64_1.5-2.dsc
 d72628f99780ee0a00a442478a2a02afa4341ad659e5111edb8f4b55b7fe67c0 24411 base64_1.5-2.diff.gz
 e4172a6d1fdecfe29697549eb8b0c97aca5f9dbd97594b70ebd831d4f36bab5b 1938 base64_1.5-2_i386.deb
Files: 
 ff74c92dd2ae717d3828954d6df7459f 1052 utils optional base64_1.5-2.dsc
 7c854e693c1ab069709ba6aa7ee16200 24411 utils optional base64_1.5-2.diff.gz
 3d6df81da7851bb90439aaf9aad796f7 1938 utils optional base64_1.5-2_i386.deb

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

iD8DBQFJrGex2N9T+zficugRArEDAJ4grT3NOuKp2NkP/S5ANn9h2ENOBACeN3Rn
A3aiwiS1ltGJOnidaBDZYF0=
=ZXD0
-----END PGP SIGNATURE-----

On 03/01/2009 05:42 PM, Michael Prokop wrote:
> 
> Sorry, I don't really understand what you mean. :) base64 isn't
> necessary anymore if you are using coreutils >= 6.0-1, so you can
> just remove base64 from your system and upgrade coreutils, that's
> what the 'Conflicts: coreutils (>= 6.0-1)' in the base64 says as
> well. Isn't this working for you?

I am not sure how this acutally should be solved but trying to
install base64 (i.e. for somebody who does not know that base64 is
now in coreutils in Debian/Lenny)) will break the system and I
wonder if there is not a cleaner way to tell "hey, use coreutils
>=6.01!" than trying to remove coreutils (and therefore everything
which depends on it).

It may be a minor thing but I've never had that before (except when
mixing distributions - which may be the case here).

To say it again: I was thinking of something opposite of Provides:
base64 (in coreutils). And as I am aware that you're not the
maintainer of coreutils it may be something like "is provided by
coreutils" (in base64) not replacing it (which is the case if you
try to install base64.

I am sorry if I express the subject unclearly but it's hard to explain.

Greetings,
 - Darsha

* Darshaka Pathirana <bts@bts.grml.org> [20090301 16:06]:

> After finally upgrading my box to Debian/Lenny and grml-2008.11 I
> noticed that base64 conflicts with coreutils (>= 6.0-1) (most probably
> because base64 is included in the newer coreutils).

> I was thinking of a solution (instead of removing base64 from the
> repository) and found this in [1]:

> [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

> .-------------------------------------------------------------------
> |A Conflicts entry should almost never have an "earlier than" version
> |clause.  This would prevent dpkg from upgrading or installing the
> |package which declared such a conflict until the upgrade or removal of
> |the conflicted-with package had been completed. Instead, Breaks may be
> |used (once Breaks is supported by the stable release of Debian). 
> `-------------------------------------------------------------------

> Maybe this is the one needed to make base64 correct but maybe not, you
> decide...

> base64 is not (and should not be) installable in Debian/Lenny but also
> also prevents any older versions of coreutils to be upgraded. Just
> wanted to let you know.

Sorry, I don't really understand what you mean. :) base64 isn't
necessary anymore if you are using coreutils >= 6.0-1, so you can
just remove base64 from your system and upgrade coreutils, that's
what the 'Conflicts: coreutils (>= 6.0-1)' in the base64 says as
well. Isn't this working for you?

regards,
-mika-

Hi!

After finally upgrading my box to Debian/Lenny and grml-2008.11 I
noticed that base64 conflicts with coreutils (>= 6.0-1) (most probably
because base64 is included in the newer coreutils).

I was thinking of a solution (instead of removing base64 from the
repository) and found this in [1]:

[1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

.-------------------------------------------------------------------
|A Conflicts entry should almost never have an "earlier than" version
|clause.  This would prevent dpkg from upgrading or installing the
|package which declared such a conflict until the upgrade or removal of
|the conflicted-with package had been completed. Instead, Breaks may be
|used (once Breaks is supported by the stable release of Debian). 
`-------------------------------------------------------------------

Maybe this is the one needed to make base64 correct but maybe not, you
decide...

base64 is not (and should not be) installable in Debian/Lenny but also
also prevents any older versions of coreutils to be upgraded. Just
wanted to let you know.

HAND,
 - Darsha