Hi Jonas,
Jonas Smedegaard wrote:
> 1) gs-common is not a "dummy" package as it does serve a purpose.
>
> Currently gs-common serves the purpose of avoiding some corner-case
> oddity transitioning from the multiflavored gs-gpl/gs-esp/... to the
> current unified one. Yes, that unification happened prior to Lenny,
> but I believe for maximum reliability during upgrades we should keep
> clutches around until after transition+1 release which in this case
> means *after* Squeeze can we drop gs-common (and gs-gpl and gs-esp,
> but that's a separate issue).
>
> We can clarify this by calling gs-common a "clutch" package rather
> than a "dummy" package.
Could you explain this further? From the user point of view, it is
very confusing, because:
1. ghostscript has Provides: gs-common
That makes it look like the standalone gs-common package is
obsolete and only kept around for the sake of other packages’
dependencies.
2. the gs-common package description says “This dummy package is
provided for a smooth transition” [etc]
That makes it look like it is safe to remove that package and
like the dependency of ghostscript on gs-common is a bug.
3. gs-common has Priority: extra, ghostscript has Priority: optional
Since ghostscript depends on gs-common, that violates policy §2.5.
4. gs-common has Depends: ghostscript, ghostscript has Depends:
gs-common (>= 8.63.dfsg.1-1)
Dependency loops like this make upgrades harder to understand.
5. ghostscript has Conflicts: gs-common (<< 8.63), Replaces:
gs-common (<< 8.63).
That makes it seem that ghostscript is the modern replacement
for old gs-common.
The gs-common preinst seems to do some removal of old
alternatives; what is that about? Is the old prerm broken?
Re upgrades from etch, I did not think Debian supported that.
Typically it is assumed in package maintainer scripts that
an upgrade never skips a full release.
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
