-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
package ghostscript cups
forcemerge 532916 534799
thanks
On Mon, Jun 29, 2009 at 04:19:50AM -0400, Jan Muszynski wrote:
>The question I have (which cannot be fixed in cups itself) is should
>the dependency on cups within ghostcript-cups have a version attached
>to it? ghostscript-cups needs cups in order to function. Fine, that's
>why it has the dependency. But will it function with any version? Or
>does it need the version that's currently in sid? If it needs the
>version currently in sid then the dependency on cups should be
>versioned. That's all.
ghostscript-cups do *not* need cups to function. If it did, it should
depend on, not just recommend, cups.
ghostscript-cups has little _use_ without cups, which is the reason it
recommends cups.
>This isn't a huge deal since once cups itself finally moves down to
>testing it will self-correct. But in the meantime it will be
>problematic.
No changes to ghostscript-cups could solve the current temporary
confusion.
These changes could have avoided the confusion (but that's too late now,
I guess):
* NEWS entry in cups warning about the new recommendation
* ghostscript-cups dependency in cups-driver-gutenprint and similar
raster drivers
>Someone upgrading ghostscript will have no way of knowing that the new
>ghostscript-cups package exists (which was why I suggested a suggests
>dependency). Someone that finds the new package won't be aware that
>they need the version of cups in sid rather then the version they
>already have installed (assuming they run testing. If they run pure
>sid they're already in synch). Since ghostscript-cups obviously
>depends on cups (as the dependency correctly states) I just feel that
>it should version the already existing dependency to indicate it won't
>work with the version of cups it finds in testing. The version found
>in sid appears to work just fine - so no bug in that version of cups.
I believe it works fine with cups - either the sid or the Lenny release.
What does not work is package dependency resolving. It does not make
sense to me to add "Breaks:" hint to other packages for broken
dependencies only - installing ghostscript-cups does _not_ break cups.
>>>Ghostscript itself should possibly have a recommends, or at least a
>>>suggests, on ghostcript-cups.
>>
>> No: Ghostscript benefits in no way from the contents of
>> ghostscript-cups.
>
>But the contents of said package were, prior to this point, part of
>ghostcript itself. So in a twisted sort of way you're stating that
>ghostscript doesn't benefit from itself :)
>>
>> I will now close this as it is not a bug in ghostscript.
>
>OK - can you reassign to ghostcript-cups? :)
Fair enough: merging with existing bug in cups, then :-P
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEAREDAAYFAkpIkSIACgkQn7DbMsAkQLjD2gCeNMgtQN5BuZGCJPLiVXh9FFNp
Tg4Anja4n/KkrrCyDWsDkJLwXPU7//lB
=IIVL
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
