Sorry for the late reply to this. On Thursday 10 April 2008, Otavio Salvador wrote: > Frans Pop <elendil@planet.nl> writes: > > On Thursday 10 April 2008, Otavio Salvador wrote: > >> I thought about Joey's comment and I believe that every call to > >> apt-install should mean that a package is required. So the package > >> will be installed in all installation methods. This makes the same > >> installation result on all available methods them. > > > > I assume that this means you have done a complete inventory of all > > cases (and for all architectures) where we call apt-update and whether > > or not the package really is required? > > > > If not, then this is a completely empty statement that I'll happily > > ignore. > > I think that this kind of answer adds nothing to the thread and I do The problem is that you say "I thought about Joey's comment", but after that you only give an _opinion_. You don't give any _argumentation or facts_ to back up that opinion. Basically that means the only thing I can do is say "I don't agree with you"; I cannot really provide any arguments myself as I don't know what I'm arguing against. So, I agree that my reaction was a bit strong, but it was only strong because you basically _always_ do this: give (IMO empty) opinions without providing any arguments. So: you are completely right that my answer adds nothing to the discussion. But, neither did yours! And that was the point I wanted to make. > believe we don't need to go throught all the internals right now but > talk about the apt-install concept and what it represents for the > enduser. I'll focus on the discussion and it's up to you to ignore it > or not. I hope other people doesn't ignore it. > Currently apt-install usage differs from this concept and I'm aware of > it; is this what is more logical to enduser? > > I think that different installation methods shouldn't have different > final results and this looks logical to me. For this to be done, the > only way I see is if all apt-install calls are "required to be > satisfied". OK. This something (though still somewhat vague and unsubstantiated) that I can actually reply to. So, let's go. In Debian in general we have several classes of packages: essential, standard, optional, etc. I hope you'll agree that distinction is useful. IMO during installation we have the same: some packages are more required than others. Anything apt-install'ed that's needed to successfully reboot the installed system in 100% required and failure to install them should result in errors. > What use cases do you see that apt-install calls should be used as > "non-required" action? I think that for example a failure to apt-install installation-reports should not result in an error being displayed, and certainly not in the installation as a whole being failed. The same goes for acpi and (IMO though I know you don't agree) laptop-detect. Or are you saying that you think apt-install should not be used to install such packages? That seems dumb to me as it would mean we'd need a different, but almost identical script, to handle those other packages. Seems better to me to make apt-install flexible enough to handle both. There are some restrictions in the implementation too here. IMO we don't want 31 levels of "requiredness", each with its own error message (if only because of translations overhead). My current implementation allows for only one error message in apt-install itself: the installation of package(s) <packages> failed; this may affect the correct functioning of the installed system. I hope you'll agree that that message is not suitable if installation of installation-reports fails. My implementation also supports the following cases: - package is not essential, so errors can be ignored - package is queued and installed during base-install; apt-install should do the error handling - package may be queued or installed directly and apt-install should do the error handling - package will always be installed directly and error handling is done by calling script I hope that I've now made _my_ arguments totally clear. Back to you (and others of course). Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.