FTR: Please don't CC me on list mail. I'm tired of setting M-F-T. Tomasz Rybak <tomasz.ry...@post.pl> writes:
> Dnia 2012-07-12, czw o godzinie 15:46 +0200, Gergely Nagy pisze: >> Tomasz Rybak <tomasz.ry...@post.pl> writes: >> >> > At first I thought it was a joke. But no, you really suggest that >> > everyone who wants to have up-to-date desktop environment >> > but without few packages (e.g. N-M or GDM) needs to create own package, >> > own local repository, and looks into it every time there is upgrade >> > to keep it current? And this is supposed to be simple? >> >> Please read the rest of the mail, and the rest of the thread, where I >> explain that Recommends gets you into the same manual bookeeping >> situation anyway. > > I might be misunderstanding situation with dependencies here then. > > Let's assume that I have set my system to install recommended > packages by default and I try install "gnome" package. > It has some packages in Depends, some in Recommends. > If it has N-M in Recommends, I can unselect it during installation. Yes. And you can remove it later too. > This will result with my system having gnome with all its dependencies > and recommendation installed except for N-M. Yes. > Then some time later during upgrade it'll upgrade all packages > but will not install N-M; at the same time it'll install > new package that was added to Recommends in that new version. As far as I remember, it will not install new recommends. > It this correct description of apt behaviour, or have > I misunderstood something? More or less, except that to the best of my knowledge, it will not install new recommends on upgrade. And that makes sense, and is good so, otherwise it will attempt to install all recommends I explicitly did not install on each upgrade - no thanks. (Or we need to introduce yet another complexity into the system, to mark packages as not-to-install-ever. I doubt we have that now... but perhaps hold on an uninstalled package works that way? I don't know.) But, the problem I'm talking about is not related to this. The problem I see is when I have a gnome meta-package, that recommends, say, totem. Now, lets suppose I'm also running unstable, for one reason or the other, and a transition comes along, and something has a breaks on stuff totem depends on, and the package manager decides to remove totem. Weeks later, when I want to watch a movie, at the end of the world, with no network connectivify, I realize that something pulled my movie player out of me. I would be very, very sad. Of course, silly me, why do I run unstable? And why don't I pay attention to what my upgrades do? Well, I run unstable because I work with it, and it has up-to-date stuff I have to work with. And running unstable is far easier than running testing and cherry-picking (did I mention I hate manual bookkeeping?). I do unattended upgrades, because I trust the system to keep everything I installed, installed. I installed the gnome meta-package because I want the full thing, bells, whistles and crap included. I could, of course, mark totem manually installed, but then I'm back to manual bookkeeping, could've installed the whole stuff by cherry-picking each component, and that makes the meta-package useless for me, and destroys the argument that recommends would result in less bookkeeping. Thus, here's an example where Recommends *will break* an existing system. Oh, and since apt won't install new recommends on upgrade, to the best of my knowledge, I won't get totem back once the transition/breakage/whatever is fixed, either. While if it would be a dependency, the upgrade would abort, because it'd try to remove a package marked as manually installed. But similarly, if I ran stable, and one of the meta packages I installed had a recommends on a piece of software, and I try to install something that conflicts with it (either directly, or indirectly, via another meta package, for example), then this piece of software gets removed. I may or may not notice that - I might not even know wtf totem is, a novice user who first sees Linux certainly won't - so it gets removed. It won't come back, unless I install it. As far as I'm concerned, this defeats the purpose of the meta-package, because it breaks my expectation that whatever else it pulls in, will stay there as long as the meta is installed. Perhaps that is a silly assumption, but if it is, then there's no point in having anything in a meta's depends at all, as it's pretty much a supermarket you can cherry pick from. In that case, I would be very disappointed. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hatd6l1n.fsf@algernon.balabit