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

Bug#631103: /usr/bin/apt-get: [multiarch] apt-get update probably shouldn't complain about missing files for non-native arch



On Mon, Jun 20, 2011 at 12:22, Mike Hommey <mh@glandium.org> wrote:
> On Mon, Jun 20, 2011 at 12:13:30PM +0200, Julian Andres Klode wrote:
>> On Mon, Jun 20, 2011 at 12:07:55PM +0200, Mike Hommey wrote:
>> > W: Failed to fetch http://mozilla.debian.net/dists/experimental/Release  Unable to find expected entry 'iceweasel-5.0/binary-armel/Packages' in Release file (Wrong sources.list entry or malformed file)
>> >
>> > The repo doesn't contain anything about armel at all. While I do understand
>> > this can be an important piece of information in some cases, in cases like
>> > this one, it is unnecessarily annoying.
>> I think it's absolutely reasonable. The default is to get sources for all
>> requested architectures. If you don't want APT to fetch armel files for
>> that source, use
>>   deb [arch=amd64,i386] http://mozilla.debian.net/ experimental iceweasel-5.0
>> instead.
>
> So should we advocate that all private repositories use that syntax to
> limit to the architectures they support?

No, we should advocate that administrators write their sources.list so that
they represent what they really want.

If the admin just wants amd64 and i386, why not write it down?
If the admin wants armel, why should APT silently ignore his request just
because the archive hasn't armel yet. And what happens if it is added later?
Or if the admin misspelled an architecture - silent ignorance?

The error message is not the nicest one on earth and we should work on that,
but as something was requested but can't be satisfied the result should be an
error (or as in this case even "only" a warning).

I know that the result will be that archive maintainers will add empty
architectures for their lazy users, but that is not a good idea and
hopefully at least a few users will complain later that armel is promised
but not provided.


Best regards

David Kalnischkies



Reply to: