[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#273734: education-common: con't fulfill the Recommends on !i386



On Sun, Oct 03, 2004 at 10:23:58AM -0400, Kevin B. McCarty wrote:
> Martin Michlmayr wrote:

> > FWIW, I agree with Adrian's interpretation [*].  "the packages in
> > main" "must not require a package outside of main" for "execution"
> > (... "Recommends").  While this sentence is fulfilled on i386, it is
> > violated on !i386 which imho is a Policy violation.

> What would you say about the case of a source package that produces some
> Arch: any packages and some Arch: all packages, but which is only
> compiled for certain architectures?  For instance, cernlib isn't
> supported on 64-bit, so I've had it added to Packages-arch-specific.  It
> has some Arch: all packages that depend or recommend Arch: any packages,
> ==> said Arch: all packages are uninstallable (or have an unsatisfiable
> Recommends) on {alpha,amd64,ia64}.  Is this considered to be against policy?

Depending on Arch: any packages is pretty clearly ok, as a package that
depends on an unavailable package is presumed to be unusable and won't
be installed.

Recommending an unavailable package is not as clear-cut, since
installing the package works in violation of the package relationship
without the *user* choosing to override the recommendation.

> If so, I am not quite sure what to do about it, since making some of the
> data packages Arch: any would tremendously bloat the archive.  I guess
> they could just Suggest the relevant libraries, but this sort of twists
> the meaning of Recommends vs. Suggests -- no one would want to have a
> data package installed without the corresponding library package.

Do the library packages not have dependencies on the data packages?  In
general, it doesn't seem like people are going to select data packages
for installation by themselves anyway; which of course also means that
the impact of an incorrect relationship is also reduced.

-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: