Re: Recommends for metapackages
Jean-Christophe Dubacq jcduba...@free.fr writes: On 11/07/2012 11:12, Andrei POPESCU wrote: On Mi, 11 iul 12, 10:55:16, Jonas Smedegaard wrote: The feature of _allowing a subset of packages to be removed that was _ensured_ to be installed: Impossible without defeating the feature of _ensuring_ those same package are installed. Agreed. However, unless I missed something I haven't seen any arguments for why gnome-core really needs to _ensure_ that network-manager-gnome is installed, other than upgrade issues without any other details. If my memory does not fail me, support from upstream (since network-manager is a core component of Gnome). I may be wrong. That must be an upstream *Gnome* bug then. But it is most certainly a bug. Network Manager is not intended as an one-size-fits-all application. I have never been a great fan of Network Manager, but for various reasons I've taken some time to actually get to know it lately. And that has been enlightening. Turns out that it works really well for the use cases it supports, and it isn't *meant* to be used for every possible use case. Contrary to what you would be led to believe by the strict Gnome dependency. I do recommend everybody, especially the Debian Gnome maintainers, to read what Dan Williams said here yesterday: https://mail.gnome.org/archives/networkmanager-list/2012-July/msg00168.html quote Instead, I believe our goal is to make NM useful enough, easy enough, and understandable enough, that people *want* to use NM rather than wading through a bunch of scripts. We don't want to force NM upon people; instead we need to make NM *better* than the existing options so that it's a no-brainer choice. There will always be people that want to tinker and do something else or have so totally crack-rock use-cases that we have no hope of easily supporting them, and that's fine. That's what software is about. Instead, I believe our goal is to make NM useful enough, easy enough, and understandable enough, that people *want* to use NM rather than wading through a bunch of scripts. We don't want to force NM upon people; instead we need to make NM *better* than the existing options so that it's a no-brainer choice. There will always be people that want to tinker and do something else or have so totally crack-rock use-cases that we have no hope of easily supporting them, and that's fine. That's what software is about. /quote I just wish every piece of software was based on a philosophy like that. Bjørn -- 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/87hasonzt2@nemi.mork.no
Resume [Was: Re: Recommends for metapackages]
Thanks to the advice of a good man, I'll try to resume my point of view to avoid repeating once and again. First, I find ground on our Policy: Recommends This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. Gnome can not work without GTK. But it can work without Network-Manager. Gnome and GTK will be found together always (at least, everytime Gnome is installed). Gnome and Network-Manager will be found together in all usual installations, but not on unusual ones. People who wants Gnome with all bells and whistles but find that Network-Manager does break their systems are not the core of our user base, but they are a considerable sector of it. Their installations qualify as unusual installations since they are not the majority, and they are enough to fire this rule. The rule does not distinguish between binary packages and metapackages. Second, Debian is not Gnome. With this I want to make clear that Gnome view about what is and what is not core on their desktop (not to forget it's theirs) is important, but it should be not conclusive. Our duty as a distribution who cares for its users is to start with upstream software with upstream views and decisions, and the to put it together for a working set that fits our users. Sometimes we need to patch code, sometimes we need to remove pieces that are non-free, sometimes we divide codebases into several packages, for the sake of easing the management of Debian and the wellness of our users. As an example near to the thread, gnome nor gnome-core packages depend on Mono, while it is considered core by upstream. Third, Network-Manager is not any other piece of Gnome. It should be trated differently from other like, say, Epiphany or Evince. Let's see the cases. * For Epiphany, where epiphany-browser, which is a Depends of gnome-core, is installed in every (Debian) Gnome distribution, there are alternatives. If a user wants to use Chromium or Firefox or Konqueror instead, Epiphany will not interfere. User just installs the desired package (well, we do not provide Firefox as is, but a rebranded one that enhances my second point) and he's working. Also, if user wants to remove the unused epiphany-browser package, he can do so since there is a declared alternative Depends: gnome-www-browser, and if user has iceweasel or chromium installed he will be fine and nothing will break (not the same for Konqueror). * For Evince, situation is a bit worse. It can be freely ignored if you want to use, say Okular or Xpdf, and it will still not interfere with you way of working, but you can not remove it without getting your whole desktop uninstalled. Anyway, since it does not annoy the user, it can be simply ignored. *For Network-Manager, situation is very different. It breaks the network configuration of some users (a sensible fraction of), so it is not a simple case of I want to use another program/method of doing foo. It is a case of This program needs to go out of my system. It can not be simply ignored and an alternative used, since N-M messes with the alternative if it is installed. Fourth, the chain that forces installation of netowrk-manager from gnome is quite curious. There are other chains that link even dpkg with gnome-manager like this one: dpkgSugiereapt apt Sugiereaptitude | synaptic | wajig wajig Sugierereportbug reportbug Sugiereclaws-mail claws-mail Dependelibpisock9 libpisock9 Sugiereevolution evolution Sugierenetwork-manager But those are chains of Suggest, that are not installed by default. Instead, look at this: gnome Dependegnome-core gnome-core Dependenetwork-manager-gnome network-manager-gnome Dependenetwork-manager This is a quite stronger Depends chain, but carefully looking at it it happens that it jumps through a package that installs just an applet. I do not see how it is correct that an applet (network-manager-gnome) ends up breaking the network configuration deserves being a Depends chain. Fifth, gnome-core is just core components. I do not see an applet fit there, an applet is more likely on all bellas and whistles space, so it should not Depends on network-manager. Sixth, the amount of work needed for Debian to have gnome-core Recommends network-manager-gnome is minimal. The amount of work saved for our users (those of them who need to get rid of network-manager) is enormous. Seventh, the user by user solutions previously proposed on this list do not fit majority of our users. I'm very happy that our developers have such a level of familiarity with packaging tools and scripting: that makes Debian a better distribution, but our users do not have such skills. If a user asks me
Re: Recommends for metapackages
]] Russ Allbery I would usually just install gnome-core once on a new system, unmarkauto the leaf packages, and then purge gnome-core and network-manager. Unfortunately, the drawback of that is that if gnome-core later adds new packages, I don't pick them up by default. Due to those drawbacks, I've wondered why people don't just disable NetworkManager on their system instead of bothering with workarounds like the above or dpkg -P --force-depends and similar. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87a9z2awjs@vuizook.err.no
Re: Recommends for metapackages
Wouter Verhelst wou...@debian.org writes: On Tue, Jul 10, 2012 at 04:18:17PM +0200, Gergely Nagy wrote: Eugene V. Lyubimkin jac...@debian.org writes: On 2012-07-10 15:32, Josselin Mouette wrote: Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : What's wrong with Recommends: in that case? It seems to perfectly match the makes life easier for common but not universal use-case XXX scenario you describe. Recommends is wrong for metapackages because it gets upgrades very wrong. This is why it is used very marginally. Standards should not depend on implementation details. I see zero reasons why metapackages are (or should be) specific here. Whatever $it that gets upgrades wrong should be fixed instead. But the purpose of the meta-package is to pull stuff in. Depends does that, Recommends does not, therefore Recommends is not appropriate for the task. Of course it does. Five years ago, when apt didn't install recommends by default, recommends might not have been appropriate, but these days it is. Does it pull in recommends on upgrade? No? Just how useful are they then, for following the changes in the meta? Does Recommends guarantee that the platform will stay intact, unless I explicitly remove a recommended package? No? That'll be fun! I installed gnome, but an upgrade wants to remove totem! What's up with that?? Is no better than I installed gnome, but an upgrade wants to remove it altogether, except the former is more dangerous, as it wants to remove a package you didn't install by hand, and may not know what it does. For novice users, the former is far more dangerous, because they may not know what the removed package is for. At least with Depends, the same upgrade would want to remove the Gnome metapackage, and they'd know what THAT is, and can stop the upgrade. No, recommends are a terrible idea for meta-packages. -- |8], who still doesn't like being CC'd on list mail. -- 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/87a9z4tcbd@luthien.mhp
Re: Recommends for metapackages
Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy Instead of fighting for Recommends, which would break your system in various interesting ways later on[1], there's a third solution: noone stops anyone from uploading a gnome-minimal package, which depends on gnome-session and a few selected other parts, without n-m. I would think it quite rude to trample on the gnome-* namespace unless this is well coordinated with the GNOME packagers. If they're happy with it, that's a different situation. I agree. But from what I've seen so far, it seems to me that it would be far easier to persuade the relevant people to accept a new meta, than to downgrade anything to Recommends. (Also a much better idea than Recommends :) -- |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/87629stc7k@luthien.mhp
Re: Recommends for metapackages
Andrei POPESCU andreimpope...@gmail.com writes: On Jo, 12 iul 12, 15:46:05, Gergely Nagy wrote: X) Downgrade stuff to recommends I do not consider this a solution, for reasons explained elsewhere, where my main concern is that it breaks the assumption that installing a platform (in this case, gnome) will install the whole thing, and it will be available for my use at any time. Well, it will, in all but unusual installations :) No. See below. With recommends, there's a fair chance that a distinctly related package forces part of the platform off, and the package manager will happily remove them. Once the breakage is fixed, it will not reinstall them. Could you please elaborate on that? The only thing I can think of that would force some packages to not be installed (or removed) is a Conflicts (or unsatisfiable Depends, but this shouldn't happen in stable). As far as stable is concerned, a conflict, yes. For unstable, where package releations are more interesting, unsatisfiable Depends too. With Recommends you get a simple prompt that a specific package will be uninstalled and comparing the descriptions will probably give a hint to any user that those packages might conflict (assuming they don't look at the Conflicts). So, on each upgrade, the user would need to: - Double guess the system, to not botch an upgrade - Read N number of package descriptions to figure out wtf that thing it wants to remove is. How is that user friendly and good? With Depends aptitude will suddenly want to remove a whole bunch of packages (that may or may not look related) and apt-get will suggest you to do this via autoremove. Then you have go hunting with apt-mark, yay! With Depends, I will instantly know something is botched. With recommends, it will happily remove half the platform unless I stop it manually. Which I most likely wont, as I'm doing unattended upgrades. And I do unattended upgrades, because I trust the system to do the right thing, and not remove stuff from under me that it should not. I *hate* doing things manually, that's why I'm using a bloody high-level package manager. If it forces me to double-guess it, check a lot of things during upgrades, I might aswell go back to downloading packages by hand and using dpkg directly myself. This can be worked around by removing the auto-installed flag from those parts of the platform that I want to keep at all times, but then what is the use of Recommends, when I have to cherry pick anyway? I could just skip installing the meta, the net effect is the same (except, that without the meta, there are no expectations to break). Are you talking about testing or sid? Either. I still don't see the problem with installing a subset by hand. Advanced users can script it, novices will only need to hand pick once. Done. 10 minutes job. IMO the main problem is: # aptitude remove package Following packages will be removed: [Big list with 100+ packages] How is that better than: # aptitude upgrade Following packages will be removed: [A list of 10+ packages you have no clue about] A novice user will answer no to the former, and keep his system intact. He will answer yes to the latter, because he never heard of those packages before, and trusts the package manager to do the right thing. Hi, you have a broken system. But, it can also happen when you remove a dependency of a recommended package: # aptitude remove dependency-of-a-recommended-package [ List of 10+ packages you have no clue about ] There goes your video player, your audio player and probably a bunch of other things. Unless the user double-checks what those 10+ packages are, which most likely he won't. Compare that to the hours wasted trying to figure out what forced part of the platform off my system and when, during an unattended upgrade.. Yes, I do those, because I want to trust the system doing the right thing, and keeping stuff I installed intact and complete. Sorry, I thought we were talking about stable, why would something like that happen. If we're talking about stable only, there's even less reason for Recommends. -- |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/87y5morx0a@luthien.mhp
Re: Recommends for metapackages
Andrei POPESCU andreimpope...@gmail.com writes: On Jo, 12 iul 12, 12:10:29, Gergely Nagy wrote: Erm, how have I broken my system? I did not. (Turning Install-Recommends off is definitely not breaking my system, FYI.) It means you are running with a non-default configuration and you should be aware of the side-effects. I am aware of side-effects, thank you. I turn it off because of the side-effects. That does not make my system broken, however. Please don't forget that a Recommends will pull in packages in all but unusual installations :) But also keep in mind, that once a package is installed, adding new recommends will not pull those new things in on an upgrade. I do not think upgrade is an unusual situation, fwiw. For stable, it is, for everything else, not so much. But half the arguments for Recommends (with regards to meta-packages) are invalid for stable anyway. The only valid argument for stable is that apt-get remove gnome will want to remove a whole bunch of stuff. My counter argument is that doing so is safer than screwing up the user's system. -- |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/87txxcrwu3@luthien.mhp
Re: Recommends for metapackages
Andrei POPESCU andreimpope...@gmail.com writes: On Jo, 12 iul 12, 17:44:52, Gergely Nagy wrote: 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. http://lists.debian.org/caaz6_fdtaydt1ubp08yf0d8l0jusffy1rzyhvmvztfcjeoc...@mail.gmail.com Hmm, right. dist-upgrade will pull new recommends in, indeed. Well, there goes one argument against Recommends. The rest still stands, though. 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. Sorry, but IMNSHO running sid with unattended upgrades just asks for trouble. But then again IANADD, if Debian wants to optimize for this use case who am I to disagree? :) Similar issues can happen in stable, less often, and for different reasons, but the possibility still exists. Also - and this easily happens in stable too -, there's the problem of trying to remove a dependency of a recommended package. That will happily remove the recommended package, and keep the meta. A user may or may not know what those strangely named packages that get removed are, and making him look it up, and watch every upgrade like a hawk isn't exactly friendly. 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. Well, if the purpose of the Depends are to protect a novice from removing packages by mistake that surely a package manager offering to remove 100+ packages should definitely sound an alarm. Yep, and it sounds an alarm: do you want to remove all this stuff, *including* the meta? Vs do you want to remove 1/10 of that stuff, most of which you never heard of so who cares? But with apt-get you will get only two packages uninstalled (the package with the conflict and the metapackage depending on it). The big surprise will come only later, when apt-get suddenly suggest you should run 'autoremove' to get rid of some 100+ packages that look like not needed anymore. Yes. But it's easier to notice the removal of gnome (and stop it), than the removal of one of the components of the platform, of which one possibly never even heard of before, just uses, as it's part of the platform. On one hand, you have, in the depends case: # apt-get remove gstreamer-plugins-good Which will try to remove the whole world, including the meta, and that will ring alarm bells. Or in the recommends case: # apt-get remove gstreamer-plugin-good Which will remove a bunch of stuff, but leave the meta installed. In the latter case, you have gnome installed, without a video or audio player. Gnome sucks. Similarly, depends protects the novice from removing parts of the platform, it provides a guaranteed set of packages. For the advanced, there are ways around the Depends, easy ways. Recommends does not protect the novice, and offers very little advantage for the advanced.
Re: Recommends for metapackages
Gergely Nagy alger...@madhouse-project.org writes: Please don't forget that a Recommends will pull in packages in all but unusual installations :) But also keep in mind, that once a package is installed, adding new recommends will not pull those new things in on an upgrade. I've been corrected, that this statement is not valid, and a dist-upgrade will pull them in. Sorry about that. However, Recommends: will not keep them installed, so if the meta is a platform, which should be intact and complete, recommends is still not an option. -- |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/87liiorvax@luthien.mhp
Re: Recommends for metapackages
Jeremy Bicha jbi...@ubuntu.com writes: I don't claim to be a networking expert, but I believe half the conversation here is based on wrong or outdated information. My (personal) complaint about NM is that it doesn't correct correctly work with NFS mounts, I believe because it doesn't run at the right time during bootup. That's perhaps illustrative of more general practical and conceptual issues with NM: it doesn't seem to be tested with much in the way of non-standard setups, and in general seems to assume too many low-level and central system tasks that arguably aren't appropriate for software associated with a specific desktop (even if Gnome is installed on a system to make some users happy, other users of the same system may use some other desktop). GNOME considers NM to be part of GNOME Core, therefore gnome-core depends on it. Debian need not slavishly follow how upstream thinks about things. Plenty of upstreams have downright bizarre opinions about various issues (often related to the not playing nice with others), but nevertheless still make useful software. In such cases I think one of the proper tasks of a distribution is to act as a buffer between upstream and the users, installing the software in a way that works well in the actual distribution, for actual users (as opposed to the imaginary distribution and users upstream may be targeting). Obviously this can be a lot of work, which is why it's generally a good idea to defer to upstream's views when they are sane -- but that isn't always the case... -miles -- Friendship, n. A ship big enough to carry two in fair weather, but only one in foul. -- 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/87txxcp15z@catnip.gol.com
Re: Recommends for metapackages
Miles Bader mi...@gnu.org writes: issues with NM: it doesn't seem to be tested with much in the way of non-standard setups My personal feeling is that this happens because people who use non-standard setups usually start by purging NM instead of trying to spend weeks reading the source code to contribute to it. -- 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/84bojk3ybc@sauna.l.org
Re: Recommends for metapackages
Gergely Nagy alger...@balabit.hu writes: if upstream considers a package a core part of a platform, recommends *is* wrong. Er, no. Upstreams are not infallible, and are often quite fallible... Upstream's view is a good _default_, but such judgements should be made based on the reality on the ground. -miles -- Non-combatant, n. A dead Quaker. -- 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/87obnkp0sx@catnip.gol.com
Re: Recommends for metapackages
Le vendredi 13 juillet 2012 à 07:27 +0200, Tollef Fog Heen a écrit : ]] Gergely Nagy Instead of fighting for Recommends, which would break your system in various interesting ways later on[1], there's a third solution: noone stops anyone from uploading a gnome-minimal package, which depends on gnome-session and a few selected other parts, without n-m. I would think it quite rude to trample on the gnome-* namespace unless this is well coordinated with the GNOME packagers. If they're happy with it, that's a different situation. FWIW, I’m not opposed to a new “gnome-minimal” metapackage if some people deem it useful (although I remain unconvinced), but in the meta-gnome3 source. I still don’t get what you would put in it except gnome-session. I’ve been seriously unimpressed by alternate metapackages effort such as brdesktop-gnome, which always end up with obsolete or wrong dependencies. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1342166566.10559.560.camel@pi0307572
Re: Recommends for metapackages
Miles Bader mi...@gnu.org writes: Gergely Nagy alger...@balabit.hu writes: if upstream considers a package a core part of a platform, recommends *is* wrong. Er, no. Upstreams are not infallible, and are often quite fallible... Upstream's view is a good _default_, but such judgements should be made based on the reality on the ground. In that case, recommends still is wrong. Either split the package then (and then both parties win), or drop a component completely (or demote to suggests). -- |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/874npc6ooa.fsf@algernon.balabit
Re: Recommends for metapackages
[...] The amount of extra work necessary is minimal though. Not so minimal if you want your gnome set to be up to date, including new applications being installed. It is very minimal. 5 minutes of work. Been there, done that, posted the bulk of the solution, and a general outline of the rest of it to this list, in this very thread, multiple times. Please take some time to read it. But alas, I'll make it easy for you: If you want to install a meta-package, but without one of its dependencies, and want to keep up to date with it too, so you get all the new stuff added to it, and you also want to be able to remove the whole thing with one swift sweep, here's what you do: - Grab the control file of the meta-package (~1 line in shell, use grep-aptavail) - Filter out unwanted packages from depends (~5-6 lines in shell) - Create a local package, under a different name, with the updated information (~10-20 lines, use equivs) === 5 minutes so far === - Push it into a local repository (~2-3 lines, use whatever, reprepro, mini-dinstall, or cat EOF) - Put the local repo in sources.list - apt-get update install your shiny new meta-package - Hook all that into Apt::Update::Post-invoke That's it. The whole thing is under a hundred lines, and easily doable within half an hour (for the record, I implemented all of the above this morning in 17 minutes while still half asleep). That may be an easy work for you, a developer. Please, do not think about you being the centre of the Universe. A non-developer user (which may be a advanced networks operator, but no developer at all) should not need to grab the control file of the metapackage to avoid n-m messing with his carefully crafted bridges. And that's only step 1. Create a local package is out of scope for MOST Debian users, those for which we need to care. Not even talking about local repositories or hooking into package manager config. I do not care if you could do it in 17 minutes each time you need it. I really bow to you for being able to do so. But I care for the thousands of Debian users who are not, and do not want to be, developers. If you want to be super-cool, create a sourcable config file that tells the generator script what packages to filter out from which metas. Pack it up, ship a deb, everyone's happy. Same again. You may be happy, for a user this would be an Herculean task. Even better, here's an alternative solution: - Grab a list of unwanted packages - Create a dummy package with an epoch of 99, using the same name the unwanted packages. - Install them - Use the meta-package unmodified (Whole excercise doable in 10 minutes tops, including reading the equivs documentation.) This is worse, since if anytime any other package relly depends on N-M it will fail due to your dummy package. All of that took a fraction of the time than arguing here on this list, about things that can already be solved *conveniently* by anyone caring enough, in multiple ways. Obviously, most people in this thread don't, as we'd already have a packaged solution if that weren't the case. Would you be so kind to create and maintain a gnome-no-network-manager package (and a gnome-core-no-network-manager one) and update it everytime the standard ones changes dependencies? I would like to, but do not have the proficency needed. And since noone seems to have cared enough to come up with a solution that works for *everyone* (upstream, novice and advanced users alike, and maintainers too), can we drop the subject now? Gnome packages with n-m as a Recommends works for everybody (including upstream, it is just that it does not make them happy): -It works for maintainers: it is just a one-time work to move n-m from Depends to Recommends. -It works for advanced users: a package in Recommends can be removed and it will not be installed again on the next Gnome upgrade, so they have the easy solution of just removing it if that fits them. -It works for novice users: a package in Recommeds gets installed by default, so they will have their easy network managing applet. -It works for upstream: they can continue developing Gnome without caring if Debian has N-M as a Recommends, a Depends or a Foo. Most bug reports will come through Debian Developers who can triage if N-M related. If they're not happy, not our task. What we should do is to allow TWO levels of cherry-picking: the one for advanced users who want to individually select every package, and the other for users who want the whole set without a specific, molesting package. We already have the first, it's called installing by hand. The second can easily be done, see above. Agree with the first. About the second, your proposal does not meet the easy requirement for most users. Even if it does for you. If that package is not a true dependency of the core of the set, Recommends is more than justified. Upstream
Re: Recommends for metapackages
On Viernes, 13 de julio de 2012 07:33:09 Gergely Nagy wrote: [...] I *hate* doing things manually, that's why I'm using a bloody high-level package manager. If it forces me to double-guess it, check a lot of things during upgrades, I might aswell go back to downloading packages by hand and using dpkg directly myself. I *hate* doing things manually, that's why I'm using a bloody high-level metapackage. If it forces me to deinstall N-M by hand using --force-depends (because it breaks my Pidgin) every time I use aptitude to install something, either related or unrelated to Gnome, I might aswell go back to downloading packages by hand and using dpkg directly myself. Regards Noel Torres er envite signature.asc Description: This is a digitally signed message part.
Re: Recommends for metapackages
On Viernes, 13 de julio de 2012 08:05:10 Gergely Nagy wrote: [...] On one hand, you have, in the depends case: # apt-get remove gstreamer-plugins-good Which will try to remove the whole world, including the meta, and that will ring alarm bells. Or in the recommends case: # apt-get remove gstreamer-plugin-good Which will remove a bunch of stuff, but leave the meta installed. In the latter case, you have gnome installed, without a video or audio player. Gnome sucks. No. You have decided to remove gstreamer-plugins-good, so you should have a reason for that, and know why you issued such a command with such an strange- named package. So you will not think Gnome sucks because it does not play video. You will think It is normal that Gnome does not play video using gstreamer, I decided to remove one of its components. Thanks god I installed Xine. [...] Did you consider creating your own meta-package? It shouldn't take you more than 5 minutes to write an apt hook to get the control file and s/Recommends/Depends/ I did not, as the existing meta-package works exactly how it should, and fulfills my expectations. If it bothers you so much, you can do the s/Depends/Recommends/ too. ;) We are discussing because it does NOT work exactly how it should: It is a meta-package for a desktop that messes up unrelated things (the network) that may be deemed critical for a system. Regards Noel Torres er Envite signature.asc Description: This is a digitally signed message part.
Re: Recommends for metapackages
On Viernes, 13 de julio de 2012 08:09:58 Gergely Nagy wrote: Gergely Nagy alger...@madhouse-project.org writes: Please don't forget that a Recommends will pull in packages in all but unusual installations :) But also keep in mind, that once a package is installed, adding new recommends will not pull those new things in on an upgrade. I've been corrected, that this statement is not valid, and a dist-upgrade will pull them in. Sorry about that. However, Recommends: will not keep them installed, so if the meta is a platform, which should be intact and complete, recommends is still not an option. I want the FREEDOM of being able to remove pieces of that platform that are not critical to it. Recommends is THE optin for that. Regards Noel Torres er Envite signature.asc Description: This is a digitally signed message part.
Re: Recommends for metapackages
On Viernes, 13 de julio de 2012 08:38:47 Timo Juhani Lindfors wrote: Miles Bader mi...@gnu.org writes: issues with NM: it doesn't seem to be tested with much in the way of non-standard setups My personal feeling is that this happens because people who use non-standard setups usually start by purging NM instead of trying to spend weeks reading the source code to contribute to it. And that's obvious: most users for which this happens are sysadmins, no programmers. Regards Noel Torres er Envite signature.asc Description: This is a digitally signed message part.
Re: Recommends for metapackages
On Viernes, 13 de julio de 2012 09:38:45 Gergely Nagy wrote: Miles Bader mi...@gnu.org writes: Gergely Nagy alger...@balabit.hu writes: if upstream considers a package a core part of a platform, recommends *is* wrong. Er, no. Upstreams are not infallible, and are often quite fallible... Upstream's view is a good _default_, but such judgements should be made based on the reality on the ground. In that case, recommends still is wrong. Either split the package then (and then both parties win), or drop a component completely (or demote to suggests). That's being Manichaean. In between Depends and Suggests it exists a middle ground. Oh surprise, it is called Recommends. Regards Noel Torres er Envite signature.asc Description: This is a digitally signed message part.
Re: Recommends for metapackages
Noel David Torres Taño env...@rolamasao.org writes: I *hate* doing things manually, that's why I'm using a bloody high-level metapackage. If it forces me to deinstall N-M by hand using --force-depends (because it breaks my Pidgin) every time I use aptitude to install something, either related or unrelated to Gnome, I might aswell go back to downloading packages by hand and using dpkg directly myself. I would usually just install gnome-core once on a new system, unmarkauto the leaf packages, and then purge gnome-core and network-manager. Unfortunately, the drawback of that is that if gnome-core later adds new packages, I don't pick them up by default. I think the GNOME maintainers mentioned previously that they were fine with there being a metapackage that was gnome-core but without network-manager. They just didn't want to maintain it. While that's going to be a very silly, tiny source package, maybe the easiest path forward is for someone to volunteer to maintain that package in the archive so that everyone else doesn't have to recreate the work using equivs. (Personally, I'm a happy user of wicd.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87r4sf8iv7@windlord.stanford.edu
Re: Recommends for metapackages
Adam Borowski writes (Re: Recommends for metapackages): On Wed, Jul 11, 2012 at 09:32:19PM -0600, Philipp Kern wrote: On Wed, Jul 11, 2012 at 07:21:00PM +0100, Noel David Torres Taño wrote: Installing N-M breaks unrelated software. No. At most it breaks *related* software. Exactly, that's why it's the gnome-core package that's RC-buggy, not network-manager. Unless someone thinks a desktop environment's core function is to mess with the network, that is. I think this discussion became circular and repetitive and useless quite some time ago. It is plain that the gnome-core maintainers are not going to agree to make this change. Therefore people who want the change made should either (a) shut up and put up with the status quo (b) refer the matter to the TC. Ian. -- 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/20480.42452.712909.798...@chiark.greenend.org.uk
Re: Recommends for metapackages
[sorry for the lengthy quoting below] On 12/07/12 10:10, Gergely Nagy wrote: Noel David Torres Taño env...@rolamasao.org writes: Not so minimal if you want your gnome set to be up to date, including new applications being installed. It is very minimal. 5 minutes of work. Been there, done that, posted the bulk of the solution, and a general outline of the rest of it to this list, in this very thread, multiple times. Please take some time to read it. But alas, I'll make it easy for you: If you want to install a meta-package, but without one of its dependencies, and want to keep up to date with it too, so you get all the new stuff added to it, and you also want to be able to remove the whole thing with one swift sweep, here's what you do: - Grab the control file of the meta-package (~1 line in shell, use grep-aptavail) - Filter out unwanted packages from depends (~5-6 lines in shell) - Create a local package, under a different name, with the updated information (~10-20 lines, use equivs) === 5 minutes so far === - Push it into a local repository (~2-3 lines, use whatever, reprepro, mini-dinstall, or cat EOF) - Put the local repo in sources.list - apt-get update install your shiny new meta-package - Hook all that into Apt::Update::Post-invoke That's it. The whole thing is under a hundred lines, and easily doable within half an hour (for the record, I implemented all of the above this morning in 17 minutes while still half asleep). If you want to be super-cool, create a sourcable config file that tells the generator script what packages to filter out from which metas. Pack it up, ship a deb, everyone's happy. Even better, here's an alternative solution: - Grab a list of unwanted packages - Create a dummy package with an epoch of 99, using the same name the unwanted packages. - Install them - Use the meta-package unmodified (Whole excercise doable in 10 minutes tops, including reading the equivs documentation.) Do you really think these are reasonable solutions for your users? I am not a Debian Developer, and following any of the above instructions would take me several hours. All of that took a fraction of the time than arguing here on this list, about things that can already be solved *conveniently* by anyone caring enough, in multiple ways. Obviously, most people in this thread don't, as we'd already have a packaged solution if that weren't the case. And since noone seems to have cared enough to come up with a solution that works for *everyone* (upstream, novice and advanced users alike, and maintainers too), can we drop the subject now? Recommends does work for everyone except you. The arguments against recommends that you keep repeating appear to apply to a small subset of developers running unstable and not the users of your stable packages. Who are you developing for? Other packages use recommends without introducing the problems you have mentioned. It sounds like you think recommends is always useless and should never be used by any package. snip If that package is not a true dependency of the core of the set, Recommends is more than justified. Upstream considers it a dependency in this case, part of a platform. If you don't want the full platform, don't install the full one, select the pieces you need - it is that easy. If I wanted software exactly as released by upstream I wouldn't be using Debian. I expect Debian fix the oddities that upstreams sometimes include and make software work nicely together. In case of gnome, the package pulls together what upstream considers the GNOME platform - it is that simple. That's what recommends does. Roger -- 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/njm6d9-ji2@silverstone.rilynn.me.uk
Re: Recommends for metapackages
Le mercredi 11 juillet 2012 à 19:17 +0100, Noel David Torres Taño a écrit : So a meta-package is just a way of installing things together, and a lot more. But from those things, only dependencies should be Depends, and software that improves the collection should be Recommends. In this particular case, N-M improves gnome but it is not needed at all. By the same view, totem improves GNOME, but it is not needed at all. Gcalctool improves GNOME, but it is not needed at all. Here’s the point: those packages are *part* of GNOME. And that includes nm-gnome, too. If you want only the required components, install gnome-session. Everything else is “improvement”. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1342077817.10559.183.camel@pi0307572
Re: Recommends for metapackages
On 2012-07-12 09:23, Josselin Mouette wrote: By the same view, totem improves GNOME, but it is not needed at all. Correct. But it does not conflict with kaffeine, mplayer, vlc, xine, ... Gcalctool improves GNOME, but it is not needed at all. Correct. But it does not conflict with bc, kcalc, ... Here’s the point: those packages are *part* of GNOME. And that includes nm-gnome, too. But it does *conflict* with the alternatives. Debian's horizon extends far beyond 'just Gnome'. Andreas -- 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/4ffe8397.1090...@abeckmann.de
Re: Recommends for metapackages
On Wed, 2012-07-11 at 23:57 +0200, Cyril Brulebois wrote: Noel David Torres Taño env...@rolamasao.org (11/07/2012): Your view is irrelevant here: GNOME project considers it essential. Gnome view is the one irrelevant. This is Debian GNU/Linux, not Gnome GNU/Linux. We need to care for our users (both proficient and novice [1]), not for Gnome developers desires. And if they had a flawed design we can patch, we should do as we do with any other flawed software. Blah blah blah. What matters is the maintainers' views (as long as common sense applies). They chose to follow upstream's choices, which is usually a sane thing to do (unless upstream is crazy). If Gnome core are really convinced that NM is essential, why Gnome could be run without NM? Why not all Gnome applications are depending on NM for network detection? Why the applications that depends on NM like evolution have all a fall-back mode? I'm maintaining a package which upstream delivers as all in one (600MB) and refuses to support splitting. I've split it into 22 packages because I know and got requests from users who want to have it in machines with small disks and/or low internet. Upstream never accepted that, but I didn't gave up, because what matters for me is user not upstream Now if you don't like those choices, pick your own packages yourself, build your own meta package, or whatever. An push it to repository? Then Yes I can upload a gnome-desktop-workstation package to be used for atypical users like me Plenty of RC bugs to submit patches for. Surely more interesting than those meta packages, right? I'm not interested in patching Gnome myself, I'm a user, not a gnome maintainer/developer Cheers, signature.asc Description: This is a digitally signed message part
Re: Recommends for metapackages
Noel David Torres Taño env...@rolamasao.org writes: Yet, we try to not diverge much from upstream, and maintain a good relationship with them. If they consider it core, so can we. Those who want to hand-pick parts of a meta package, can do so, we do not forbid. If we want to be user friendly, it is not a matter of we do not forbid, it is a matter of we make easy. Besides, low-level users will install Recommends by default, so they will get the whole box anyway. But medium or high level users may probably want N-M not to mess their network EVEN if they want the whole gnome desktop set. I do not see the problem: those who want the full platform, can get it easily. Those who don't, and want to exclude some, they can do so easily too. A bit more work, but hey, if you're going to cherry pick, that will always involve more work. The amount of extra work necessary is minimal though. Not so minimal if you want your gnome set to be up to date, including new applications being installed. It is very minimal. 5 minutes of work. Been there, done that, posted the bulk of the solution, and a general outline of the rest of it to this list, in this very thread, multiple times. Please take some time to read it. But alas, I'll make it easy for you: If you want to install a meta-package, but without one of its dependencies, and want to keep up to date with it too, so you get all the new stuff added to it, and you also want to be able to remove the whole thing with one swift sweep, here's what you do: - Grab the control file of the meta-package (~1 line in shell, use grep-aptavail) - Filter out unwanted packages from depends (~5-6 lines in shell) - Create a local package, under a different name, with the updated information (~10-20 lines, use equivs) === 5 minutes so far === - Push it into a local repository (~2-3 lines, use whatever, reprepro, mini-dinstall, or cat EOF) - Put the local repo in sources.list - apt-get update install your shiny new meta-package - Hook all that into Apt::Update::Post-invoke That's it. The whole thing is under a hundred lines, and easily doable within half an hour (for the record, I implemented all of the above this morning in 17 minutes while still half asleep). If you want to be super-cool, create a sourcable config file that tells the generator script what packages to filter out from which metas. Pack it up, ship a deb, everyone's happy. Even better, here's an alternative solution: - Grab a list of unwanted packages - Create a dummy package with an epoch of 99, using the same name the unwanted packages. - Install them - Use the meta-package unmodified (Whole excercise doable in 10 minutes tops, including reading the equivs documentation.) All of that took a fraction of the time than arguing here on this list, about things that can already be solved *conveniently* by anyone caring enough, in multiple ways. Obviously, most people in this thread don't, as we'd already have a packaged solution if that weren't the case. And since noone seems to have cared enough to come up with a solution that works for *everyone* (upstream, novice and advanced users alike, and maintainers too), can we drop the subject now? What we should do is to allow TWO levels of cherry-picking: the one for advanced users who want to individually select every package, and the other for users who want the whole set without a specific, molesting package. We already have the first, it's called installing by hand. The second can easily be done, see above. If that package is not a true dependency of the core of the set, Recommends is more than justified. Upstream considers it a dependency in this case, part of a platform. If you don't want the full platform, don't install the full one, select the pieces you need - it is that easy. Similarly, if you don't want to install a full blown desktop system with a GUI, you don't select the desktop task when installing Debian. If you do want some little things later, you install those by hand. In case of gnome, the package pulls together what upstream considers the GNOME platform - it is that simple. If you don't need it all, don't install it all. If you want to follow the platform, but skip parts of it, I already presented two solutions above. You're welcome. -- |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/87hatdv0dm.fsf@algernon.balabit
Re: Recommends for metapackages
On 12-07-12 at 10:28am, Abou Al Montacir wrote: I'm maintaining a package which upstream delivers as all in one (600MB) and refuses to support splitting. I've split it into 22 packages because I know and got requests from users who want to have it in machines with small disks and/or low internet. I guess you are referring to lazarus. sarcasm Oh horror: The meta-package lazarus-0.9.30.4 forces 70MB of documentation down my throat! That's not freedom of choice, that is outragous! That package should only recommend its dependencies, for those 1-2% custom users needing the convenience of the meta-package without the burden og that documentation part. /sarcasm As with any package available in Debian: Just don't install it if you do not like what the package does! It really is that simple! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Recommends for metapackages
Eugene V. Lyubimkin jac...@debian.org writes: On 2012-07-11 14:33, Gergely Nagy wrote: Eugene V. Lyubimkin jac...@debian.org writes: Moreover, despite me understanding the picture, I still has no clean, safe and documented way to do what I'd want in case the package maintainer chosed Depends. You have: install the pieces you want by hand. That's at least clean and safe. I do not think it is worth documenting explicitly. No, this is (IMO) not a solution: [1] Script it. I believe those who are unhappy with n-m, and understand what Depends and Recommends do, are able to write 20 lines of shell. I already posted at least one solution for the problem: https://lists.debian.org/debian-devel/2012/07/msg00219.html [...] Demoting to Recommends would be less so, but if upstream considers a package a core part of a platform, recommends *is* wrong. If you disagree with upstream, you have the tools and the ability to customize your system: use a non-stock meta package. Well, disagreed here. By the logic above we, for example, cannot apply any patches NACKed by upstream. That's not nearly the same thing. It's not hard. I'd be very curious why you're so against it, perhaps we can come up with a solution that satisfies you? Because if a user who installed Debian yesterday asks me So how do I do that? I want my answer to be It's easy, just do '$packagemanager remove $singlepackage' instead of It's easy, just build and maintain a non-stock meta package How about: Install $this package, and run $that command, answer its questions, and you're done! That would: - Allow us to keep Depends as Depends - Allow users who wish to follow the meta, with parts of it removed to do so, conveniently. - Leave everyone else unaffected. Which, in turns means: - People happy with the status quo remain happy - People unhappy with have an easy, convenient solution that anyone can use without knowing a thing about meta packages or building packages or anything like it. A solution you could point a novice user to, and said user would be happy with it. Said package takes half an hour to make, perhaps another half to make it friendly. Those caring enough, could've solved the issue by now. Since there was nothing done but useless throwing of words, I'd think noone cares enough. -- |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/87d341uzsa.fsf@algernon.balabit
Re: Recommends for metapackages
Steve McIntyre st...@einval.com writes: Gergely wrote: Henrique de Moraes Holschuh h...@debian.org writes: IMO, metapackages should depend on the absolutely required stuff (and many times that will be the empty set), recommend the rest, and maybe even suggest fringe packages. This achieves maximum usability for more usecases, and malfunctions only in the unsupported case of no install recommends by default -- you should skip recommends always in a case-by-case basis. That also achives maximum annoyance, because if I want the full platform, I'll have to go recommends/suggest hunting. (No, I'm *not* going to turn on install-recommends.) Right. So you're arguing that all the packages should be listed as Depends: to make *your* life easier, when you're doing something different from what's recommended. Thanks for showing how much weight we should attach to your argument. It's a meta-package, that pulls in a platform. If I install it, I want the full platform, always. That's about it. If I install mono-complete, I want the whole bloody thing, always. If I install kde-full, I want the full KDE desktop, with all bells and whistles. If I install gnome, I want the whole thing with all strings attached. That's what I consider a meta-package's job. If I want parts of it, I will install parts of it. Metas are a convenience for the most common case: installing all of it. Lets consider another case! Suppose I have Install-Recommends turned on, and install a theoretical meta package, that has half of its stuff in recommends, because they're not strictly necessary, but merely enhance the system. Lets suppose one of these enhancements include a tool I use every once in a while, but not daily. Now, a few months later, a transition comes about, and this package I have gets removed, because another thing I update breaks/conflicts/whatevers it. Since it's a recommends only, my package manager will most likely want to remove it. I now have two options: I either notice this, and stop the upgrade, or I don't and poof, part of the platform's gone. I installed the full thing, and lost part of it. I'm not happy. As for why I wouldn't notice? Because I trust the system to do the right thing, and I do automatic, unattended upgrades. Not an uncommon thing to do, I believe. But with recommends, the system failed me here, and removed part of the platform that I *explicitly* installed. And I had Install-Recommends turned on. Thank you, I'd rather have Depends, and a reliable way to keep the full platform on my system. Would I want to remove parts of it, I already have the power to do that with the status quo. I can even keep up with the meta package easily, if I choose to do so. I don't know about you, but I prefer my systems reliable and I absolutely hate when it wants to screw me over and try to remove parts of stuff I explicitly asked it to install. -- |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/87629tuz4v.fsf@algernon.balabit
Re: Recommends for metapackages
On Thu, 2012-07-12 at 11:09 +0200, Jonas Smedegaard wrote: On 12-07-12 at 10:28am, Abou Al Montacir wrote: I'm maintaining a package which upstream delivers as all in one (600MB) and refuses to support splitting. I've split it into 22 packages because I know and got requests from users who want to have it in machines with small disks and/or low internet. I guess you are referring to lazarus. sarcasm Oh horror: The meta-package lazarus-0.9.30.4 forces 70MB of documentation down my throat! That's not freedom of choice, that is outragous! That package should only recommend its dependencies, for those 1-2% custom users needing the convenience of the meta-package without the burden og that documentation part. /sarcasm Yes, but as you can see lazarus-ide-0.9.30.4 does not pull them. And even lazarus-0.9.30.4, which is intended for a typical Lazarus installation (equiv gnome) is not forcing fpc, as you may want, to use it with gpc or even gcc (I doubt it could, but you can try why forcing a compiler?) As with any package available in Debian: Just don't install it if you do not like what the package does! It really is that simple! I think that we really do not have the same understanding of metapackage. You clearly want them strict and non flexible, I want them convenient and flexible while ensuring desired functionality. This does not end at gnome dependency but is really a general issue as stated in other mails of this thread. I really hate forcing things if not needed, just like the nature, have minimal set of constraints, but ensure they got honored everywhere they are relevant. Especially avoid dpakg --force-depends. Cheers,
Re: Recommends for metapackages
Andrei POPESCU andreimpope...@gmail.com writes: On Mi, 11 iul 12, 14:41:50, Gergely Nagy wrote: Andrei POPESCU andreimpope...@gmail.com writes: Depending on how you do the package selection on your next installation you might end up with rsyslog, but without logrotate[1]. I don't see how that would break anything. logrotate is not necessary for log rotation, not with the syslog daemon of my choice at least. And as you said yourself, log rotation isn't mandatory either. Given that I have turned off Recommends on that system because it's space constrained (it's running from a 2GB USB stick) having logs not rotated would have become a problem eventually. a) logrotate is not required for log rotation. b) You can still install it if you need it. I can also stop installing my video driver, since it's not depended on (nor recommended) by anything but the huge xserver-xorg-video-all metapackage, and then call my system broken. *shrug* -- |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/871ukhuyzx.fsf@algernon.balabit
Re: Recommends for metapackages
Abou Al Montacir abou.almonta...@sfr.fr writes: As with any package available in Debian: Just don't install it if you do not like what the package does! It really is that simple! I think that we really do not have the same understanding of metapackage. You clearly want them strict and non flexible, I want them convenient and flexible while ensuring desired functionality. A flexible meta package is useless, however. If you want flexibility, you can already install parts by themselves. If you want to remove them with one broad swipe, that is also possible (create a meta that depends on them all, so they get marked auto-installed, and install that meta; or create a dummy package that conflicts with them, and install that - both of these can be automated, and even beaten into a shape suitable even for novice users, FYI). However, if you want predictability, then Depends is your only option. And if I install a meta package, I expect it to always install the full thing, and keep those parts installed. Something that installs almost the full thing, save a few, and allows distinctly-related stuff to force removal of some of the meta is... well... unpredictable rubbish, that is just asking for trouble. Instead of fighting for Recommends, which would break your system in various interesting ways later on[1], there's a third solution: noone stops anyone from uploading a gnome-minimal package, which depends on gnome-session and a few selected other parts, without n-m. [1]: http://article.gmane.org/gmane.linux.debian.devel.general/174877 And that goes for the rest of the meta packages: you can always introduce more, customized for common needs. So, we could say to users: You don't want the full gnome platform? Neither do you want to pick parts of it by hand? Install gnome-minimal! -- |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/87txxdtj9b.fsf@algernon.balabit
Re: Recommends for metapackages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 12/07/12 11:09, Jonas Smedegaard a écrit : As with any package available in Debian: Just don't install it if you do not like what the package does! Hi, There is a major difference between the gnome-core metapackages and any other (meta) package in Debian: gnome-core is included is the desktop task that approximately one user out of three installs (this is my reading of popcon data). 4 installations _in popcon_. Lets now assume that 1% of are unsatisfied by network-manager and decide to remove it. That 400 users out of the popcon panel who need to remove the gnome-core, and even task-gnome-desktop. All of the sudden, 90% of their installed software disappears because they want to get rid of this annoying little icon that believes it knows better than them how to configure their bloody network. Note that a meta-package such as task-gnome-desktop installs most of its packages as _Recommends_, not _Depends_. 400 popcon installations is quite popular by popcon standards. It corresponds to a package in the top 30% of all Debian packages with more than 10 installs. Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/+nx4ACgkQ+37NkUuUiPH3TQCfdbb+YkVKvo7BD5IjBHRnnGe8 VKUAnikJty/OmeJlT2+Aink2pMHYF6Ib =SevA -END PGP SIGNATURE- -- 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/4ffe9f1e.3010...@users.sourceforge.net
Re: Recommends for metapackages
On Thu, Jul 12, 2012 at 11:06:40AM +0200, Gergely Nagy wrote: Right. So you're arguing that all the packages should be listed as Depends: to make *your* life easier, when you're doing something different from what's recommended. Thanks for showing how much weight we should attach to your argument. :-) Even if there seems to be no point in the discussion any more because the arguing is void - I'll try some hint. It's a meta-package, that pulls in a platform. If I install it, I want the full platform, always. That's about it. If I install mono-complete, I want the whole bloody thing, always. I think the attempt to ensure something always is not reasonable because if the admin decided to break the system in whatever way chances are low that you can do this. You also can not do this always if I as a local admin do some fancy stuff with preferences to get the dependency resolution from somewhere else or do some fancy tricks with equivs. So your always argument is void for other ways to break my machine. You have intentionally broken your system as it was defined in policy and you now try one way to fix your personal broken system on all other systems which are not broken in this specific way. I have not read the whole thread but it seems to me that you have ignored the system of recommends. Kind regards Andreas. -- http://fam-tille.de -- 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/20120712095433.gc11...@an3as.eu
Re: Recommends for metapackages
On 12-07-12 at 11:26am, Abou Al Montacir wrote: On Thu, 2012-07-12 at 11:09 +0200, Jonas Smedegaard wrote: On 12-07-12 at 10:28am, Abou Al Montacir wrote: I'm maintaining a package which upstream delivers as all in one (600MB) and refuses to support splitting. I've split it into 22 packages because I know and got requests from users who want to have it in machines with small disks and/or low internet. I guess you are referring to lazarus. sarcasm Oh horror: The meta-package lazarus-0.9.30.4 forces 70MB of documentation down my throat! That's not freedom of choice, that is outragous! That package should only recommend its dependencies, for those 1-2% custom users needing the convenience of the meta-package without the burden og that documentation part. /sarcasm Yes, but as you can see lazarus-ide-0.9.30.4 does not pull them. ...just as gnome-session doesn't depend on network-manager. And even lazarus-0.9.30.4, which is intended for a typical Lazarus installation (equiv gnome) is not forcing fpc, as you may want, to use it with gpc or even gcc (I doubt it could, but you can try why forcing a compiler?) ...just as gnome-core isn't depending on, say, evolution. As with any package available in Debian: Just don't install it if you do not like what the package does! It really is that simple! I think that we really do not have the same understanding of metapackage. You clearly want them strict and non flexible, I want them convenient and flexible while ensuring desired functionality. Then why do the meta-package lazarus-0.9.30.4 depend on *anything*? I guess it has to do with the desired functionality you as package maintainer want ensured by offering that meta-package. An offering that anyone disagreeing with is free to not take, but instead explicitly install the custom subset they prefer. I really hate forcing things if not needed, What is forced? Do you force anyone to install lazarus-0.9.30.4? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Recommends for metapackages
Hi, Le 12/07/12 11:06, Gergely Nagy a écrit : Lets consider another case! Suppose I have Install-Recommends turned on, and install a theoretical meta package, that has half of its stuff in recommends, because they're not strictly necessary, but merely enhance the system. Lets suppose one of these enhancements include a tool I use every once in a while, but not daily. A later upgrade to your beloved meta-package could very well drop this dependency. If that's a tool that you know you want, I strongly suggest you mark it as manually installed. As for why I wouldn't notice? Because I trust the system to do the right thing, and I do automatic, unattended upgrades. Not an uncommon thing to do, I believe. You should always check what your package manager wants to remove. In my experience, more often than not, aptitude tries to remove the full gnome metapackage because of a temporarily unavailable depends. Regards, thibaut. -- 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/4ffea089.4090...@free.fr
Re: Recommends for metapackages
Andreas Tille andr...@an3as.eu writes: It's a meta-package, that pulls in a platform. If I install it, I want the full platform, always. That's about it. If I install mono-complete, I want the whole bloody thing, always. I think the attempt to ensure something always is not reasonable because if the admin decided to break the system in whatever way chances are low that you can do this. And if the admin broke his system, I stop caring. Neither Recommends, nor Depends will help there. You also can not do this always if I as a local admin do some fancy stuff with preferences to get the dependency resolution from somewhere else or do some fancy tricks with equivs. So your always argument is void for other ways to break my machine. Indeed so. But that, too, is outside of the scope. When I say always, I meant it as on my system, wearing my root hat. What other people do to their system, is none of my business. You have intentionally broken your system as it was defined in policy and you now try one way to fix your personal broken system on all other systems which are not broken in this specific way. Erm, how have I broken my system? I did not. (Turning Install-Recommends off is definitely not breaking my system, FYI.) I have not read the whole thread but it seems to me that you have ignored the system of recommends. Alas, I did not, and I explained it elsewhere in this thread why and how Recommends would break expectations, and why they are inferior to Depends, as far as meta-packages are concerned. I also presented ways to improve the current situation, none of which involve Recommend, and neither would break any system, nor expectations, and as such, are superior to Recommends - at least when talking about meta packages. -- |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/87ipdtthm2.fsf@algernon.balabit
Re: Recommends for metapackages
Thibaut Paumard mlotpot.n...@free.fr writes: Le 12/07/12 11:06, Gergely Nagy a écrit : Lets consider another case! Suppose I have Install-Recommends turned on, and install a theoretical meta package, that has half of its stuff in recommends, because they're not strictly necessary, but merely enhance the system. Lets suppose one of these enhancements include a tool I use every once in a while, but not daily. A later upgrade to your beloved meta-package could very well drop this dependency. While that may happen, that is far more unlikely than the case I outlined, and a case I can live with. If that's a tool that you know you want, I strongly suggest you mark it as manually installed. Problem is, at the time I installed the meta, I did not know about this particular tool. It came with the platform, and I really do not want to care which part of the platform it is. It came with it, I expect it will stay as long as it is part of the platform. Recommends breaks that assumption. As for why I wouldn't notice? Because I trust the system to do the right thing, and I do automatic, unattended upgrades. Not an uncommon thing to do, I believe. You should always check what your package manager wants to remove. Why? In my setup, it will never remove things that are not marked auto-install. I ensure that my system works, by having all dependencies satisfied. (And any recommends or suggests I do need, I install by hand) I do unattended upgrades for a reason: I don't want to spend time on double-guessing something that should work automatically. In my experience, more often than not, aptitude tries to remove the full gnome metapackage because of a temporarily unavailable depends. Well, mine won't do that, as I don't have gnome marked auto-install, so it will abort the upgrade instead. However, if things would move down to Recommends, it would happily proceed to remove things I do use, just because I didn't install it by hand... And here we get back to the same issue others had: manual bookkeeping. But this time, with recommends. So pray tell me, how is Recommends any better, when I have to resort to manual bookkeeping anyway? -- |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/87ehohthas.fsf@algernon.balabit
Re: Recommends for metapackages
On Wed, Jul 11, 2012 at 11:25:05PM +, Sune Vuorela wrote: for the 1-2% of people who has weird needs. It's this proportion which I think is not consistent, nor agreed, amongst all developers. -- 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/20120712125919.GD11211@debian
Re: Recommends for metapackages
Dnia 2012-07-12, czw o godzinie 10:39 +0200, Gergely Nagy pisze: Noel David Torres Taño env...@rolamasao.org writes: Yet, we try to not diverge much from upstream, and maintain a good relationship with them. If they consider it core, so can we. Those who want to hand-pick parts of a meta package, can do so, we do not forbid. If we want to be user friendly, it is not a matter of we do not forbid, it is a matter of we make easy. Besides, low-level users will install Recommends by default, so they will get the whole box anyway. But medium or high level users may probably want N-M not to mess their network EVEN if they want the whole gnome desktop set. I do not see the problem: those who want the full platform, can get it easily. Those who don't, and want to exclude some, they can do so easily too. A bit more work, but hey, if you're going to cherry pick, that will always involve more work. The amount of extra work necessary is minimal though. Not so minimal if you want your gnome set to be up to date, including new applications being installed. It is very minimal. 5 minutes of work. Been there, done that, posted the bulk of the solution, and a general outline of the rest of it to this list, in this very thread, multiple times. Please take some time to read it. But alas, I'll make it easy for you: If you want to install a meta-package, but without one of its dependencies, and want to keep up to date with it too, so you get all the new stuff added to it, and you also want to be able to remove the whole thing with one swift sweep, here's what you do: - Grab the control file of the meta-package (~1 line in shell, use grep-aptavail) - Filter out unwanted packages from depends (~5-6 lines in shell) - Create a local package, under a different name, with the updated information (~10-20 lines, use equivs) === 5 minutes so far === - Push it into a local repository (~2-3 lines, use whatever, reprepro, mini-dinstall, or cat EOF) - Put the local repo in sources.list - apt-get update install your shiny new meta-package - Hook all that into Apt::Update::Post-invoke That's it. The whole thing is under a hundred lines, and easily doable within half an hour (for the record, I implemented all of the above this morning in 17 minutes while still half asleep). 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? I had phase of wanting to have under my control; heck, I even was using Linux From Scratch, to which I was writing scripts to keep it as up-to-date as possible. But later I become lazy and started to think that there is better use for my time. After some time I found Debian and liked idea of using other people's work and not having to create my own distribution. After more time I started packaging some software I am using so other people does not need to waste their time building their own packages but may use my work and just do # apt-get install python-pyopenl Do you really think that forcing many people to maintain their own repositories and metapackages is better than just moving e.g. N-M or GDM3 from Depends to Recommends? Think about all those hours wasted, times however many people who want to customise their desktops. Regards. -- Tomasz Rybak tomasz.ry...@post.pl GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Re: Recommends for metapackages
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. Unless, of course, you treat Recommends specially for meta packages... and that is supposed to be simple how exactly? Do you really think that forcing many people to maintain their own repositories and metapackages is better than just moving e.g. N-M or GDM3 from Depends to Recommends? Forcing? No. But it seems, I have to reiterate the solutions that are all superior to downgrading stuff to Recommends: 0) Cherry pick packages by hand === Advantage is obviously that this is the most flexible way. Period. Disadvantage: no easy way to remove everything in one go, and it's a bit of a burden to follow the platform. However, lets consider the average user using stable: how often does the platform change? Zero times during a stable release. Zero. You might have to follow changes during a dist-upgrade, but that, I believe, is acceptable. If you're not using stable, well, tough luck, but you made that choice consciously, and should've been aware of the downsides, which may include a bit of extra work on your part. Still, even in that case, how often does or did the list of Dependencies of the gnome meta-package change since squeeze? I don't expect it'd changed much, save for the gnome2-gnome3 transition, and most of the changes most probably wouldn't need followups anyway. If I'm mistaken, please do correct me, however. 1) Use a custom meta package The advantage here is that it's easy to do, easy to automate, and you can easily follow the upstream meta-package, excluding only a few of its dependencies. The downside is obviously that you (or a script) has to maintain a local repo. Personally, I couldn't care less what the tool that automates this for me accomplishes that, as long as it can be fully automated (it can be), but some may disagree. And it's certainly not the most elegant solution. 2) Use dummy equivs packages Instead of replacing the meta, you'd replace the dependencies you don't want installed. The advantage is that you don't have to maintain a local repo, and you get to use the upstream meta as-is. The downside is that you'll have a bunch of local dummy packages, and you have to make them. Again, that can be scripted, and completely hidden from the user. Nevertheless, this is still not the most elegant solution. 3) Upload a gnome-minimal package or somesuch = The advantage is that it will have whatever you want. The downside is that the maintainer must keep it up to date, and whoever disagrees what constutites minimal, whill continue shouting. Yet, this is straighforward, and places the burden on one person instead of everyone who might want such a package. X) Downgrade stuff to recommends I do not consider this a solution, for reasons explained elsewhere, where my main concern is that it breaks the assumption that installing a platform (in this case, gnome) will install the whole thing, and it will be available for my use at any time. With recommends, there's a fair chance that a distinctly related package forces part of the platform off, and the package manager will happily remove them. Once the breakage is fixed, it will not reinstall them. This can be worked around by removing the auto-installed flag from those parts of the platform that I want to keep at all times, but then what is the use of Recommends, when I have to cherry pick anyway? I could just skip installing the meta, the net effect is the same (except, that without the meta, there are no expectations to break). Think about all those hours wasted, times however many people who want to customise their desktops. I still don't see the problem with installing a subset by hand. Advanced users can script it, novices will only need to hand pick once. Done. 10 minutes job. Compare that to the hours wasted trying to figure out what forced part of the platform off my system and when, during an unattended upgrade.. Yes, I do those, because I want to trust the system doing the right thing, and keeping stuff I installed intact and complete. If I have to double-guess the package manager, then there is something seriously wrong. Recommends would force me to do that. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Re: Recommends for metapackages
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. This will result with my system having gnome with all its dependencies and recommendation installed except for N-M. 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. It this correct description of apt behaviour, or have I misunderstood something? Regards. -- Tomasz Rybak tomasz.ry...@post.pl GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Re: Recommends for metapackages
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
Re: Recommends for metapackages
On Thu, 2012-07-12 at 05:42 +0200, Adam Borowski wrote: On Wed, Jul 11, 2012 at 09:32:19PM -0600, Philipp Kern wrote: On Wed, Jul 11, 2012 at 07:21:00PM +0100, Noel David Torres Taño wrote: Installing N-M breaks unrelated software. No. At most it breaks *related* software. Exactly, that's why it's the gnome-core package that's RC-buggy, not network-manager. Unless someone thinks a desktop environment's core function is to mess with the network, that is. Couldn't say it better myself. Why does the desktop core mess with the network settings?? -- 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/1342125195.4582.8.camel@x60
Re: Recommends for metapackages
On Jo, 12 iul 12, 15:46:05, Gergely Nagy wrote: X) Downgrade stuff to recommends I do not consider this a solution, for reasons explained elsewhere, where my main concern is that it breaks the assumption that installing a platform (in this case, gnome) will install the whole thing, and it will be available for my use at any time. Well, it will, in all but unusual installations :) With recommends, there's a fair chance that a distinctly related package forces part of the platform off, and the package manager will happily remove them. Once the breakage is fixed, it will not reinstall them. Could you please elaborate on that? The only thing I can think of that would force some packages to not be installed (or removed) is a Conflicts (or unsatisfiable Depends, but this shouldn't happen in stable). With Recommends you get a simple prompt that a specific package will be uninstalled and comparing the descriptions will probably give a hint to any user that those packages might conflict (assuming they don't look at the Conflicts). With Depends aptitude will suddenly want to remove a whole bunch of packages (that may or may not look related) and apt-get will suggest you to do this via autoremove. Then you have go hunting with apt-mark, yay! This can be worked around by removing the auto-installed flag from those parts of the platform that I want to keep at all times, but then what is the use of Recommends, when I have to cherry pick anyway? I could just skip installing the meta, the net effect is the same (except, that without the meta, there are no expectations to break). Are you talking about testing or sid? I still don't see the problem with installing a subset by hand. Advanced users can script it, novices will only need to hand pick once. Done. 10 minutes job. IMO the main problem is: # aptitude remove package Following packages will be removed: [Big list with 100+ packages] Compare that to the hours wasted trying to figure out what forced part of the platform off my system and when, during an unattended upgrade.. Yes, I do those, because I want to trust the system doing the right thing, and keeping stuff I installed intact and complete. Sorry, I thought we were talking about stable, why would something like that happen. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Recommends for metapackages
On Jo, 12 iul 12, 17:44:52, Gergely Nagy wrote: 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. http://lists.debian.org/caaz6_fdtaydt1ubp08yf0d8l0jusffy1rzyhvmvztfcjeoc...@mail.gmail.com 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.) Pin it to -1 ;) 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. Sorry, but IMNSHO running sid with unattended upgrades just asks for trouble. But then again IANADD, if Debian wants to optimize for this use case who am I to disagree? :) 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. Well, if the purpose of the Depends are to protect a novice from removing packages by mistake that surely a package manager offering to remove 100+ packages should definitely sound an alarm. But with apt-get you will get only two packages uninstalled (the package with the conflict and the metapackage depending on it). The big surprise will come only later, when apt-get suddenly suggest you should run 'autoremove' to get rid of some 100+ packages that look like not needed anymore. 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. Did you consider creating your own meta-package? It shouldn't take you more than 5 minutes to write an apt hook to get the control file and s/Recommends/Depends/ Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Recommends for metapackages
On Jo, 12 iul 12, 12:10:29, Gergely Nagy wrote: Erm, how have I broken my system? I did not. (Turning Install-Recommends off is definitely not breaking my system, FYI.) It means you are running with a non-default configuration and you should be aware of the side-effects. The attitude that Recommends are not important is probably the reason why: 1. some Maintainers use Depends, where Recommends would be more appropriate 2. some Maintainers use Recommends, where Suggests would be more appropriate Dear Maintainers, Please don't forget that a Recommends will pull in packages in all but unusual installations :) Therefor you may be bloating your user's computer needlessly and make it really hard for them to clean up afterwards (in case of circular Recommends packages will be kept installed even if marked as auto-installed). Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Recommends for metapackages
On Tue, Jul 10, 2012 at 04:18:17PM +0200, Gergely Nagy wrote: Eugene V. Lyubimkin jac...@debian.org writes: On 2012-07-10 15:32, Josselin Mouette wrote: Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : What's wrong with Recommends: in that case? It seems to perfectly match the makes life easier for common but not universal use-case XXX scenario you describe. Recommends is wrong for metapackages because it gets upgrades very wrong. This is why it is used very marginally. Standards should not depend on implementation details. I see zero reasons why metapackages are (or should be) specific here. Whatever $it that gets upgrades wrong should be fixed instead. But the purpose of the meta-package is to pull stuff in. Depends does that, Recommends does not, therefore Recommends is not appropriate for the task. Of course it does. Five years ago, when apt didn't install recommends by default, recommends might not have been appropriate, but these days it is. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120713040331.gl2...@grep.be
Re: Recommends for metapackages
]] Gergely Nagy Instead of fighting for Recommends, which would break your system in various interesting ways later on[1], there's a third solution: noone stops anyone from uploading a gnome-minimal package, which depends on gnome-session and a few selected other parts, without n-m. I would think it quite rude to trample on the gnome-* namespace unless this is well coordinated with the GNOME packagers. If they're happy with it, that's a different situation. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87zk74i628@xoog.err.no
Re: Recommends for metapackages
On 12-07-11 at 10:04am, Ivan Shmakov wrote: Jonas Smedegaard d...@jones.dk writes: […] It is a feature (which each user is free to avoid by not using it!) for Debian to include a meta-package that pulls in that vil n-m, not a bug. … And what exactly this “feature” gives to the user? The single feature that makes anyone want to install the package: On 12-07-10 at 06:10pm, Jonas Smedegaard wrote: The very purpose of a meta-package is to _ensure_ that a certain set of packages is installed, not just recommend them: All (not only most) users of that package need all its dependencies satisfied - those that don't should simply uninstall the meta-package. Some argue that meta-packages can have a different purpose, and some argue that recommending also to some (lesser) extend ensures installation of packages. None of that, however, changes the fact that _this_ meta-package _now_ has the feature of strictly ensuring a certain set of packages. For those wanting that. And not for those feeling it is in their way, but those can simply avoid that package: A meta-package has no functionalirty beyond pulling in packages, so there is no loss to the resulting system other than lack of its sole feature. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Recommends for metapackages
On Mi, 11 iul 12, 09:10:12, Jonas Smedegaard wrote: A meta-package has no functionalirty beyond pulling in packages, so there is no loss to the resulting system other than lack of its sole feature. IMVHO a feature almost as important is to remove a set of packages. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Recommends for metapackages
On 12-07-11 at 10:45am, Andrei POPESCU wrote: On Mi, 11 iul 12, 09:10:12, Jonas Smedegaard wrote: A meta-package has no functionalirty beyond pulling in packages, so there is no loss to the resulting system other than lack of its sole feature. IMVHO a feature almost as important is to remove a set of packages. The feature of _removing_ a set of packages: aptitude remove ... The feature of _ensuring_ a set of packages is not installed: Make a meta-package that conflicts with the packages. The feature of _allowing a subset of packages to be removed that was _ensured_ to be installed: Impossible without defeating the feature of _ensuring_ those same package are installed. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Recommends for metapackages
On Mi, 11 iul 12, 10:55:16, Jonas Smedegaard wrote: The feature of _allowing a subset of packages to be removed that was _ensured_ to be installed: Impossible without defeating the feature of _ensuring_ those same package are installed. Agreed. However, unless I missed something I haven't seen any arguments for why gnome-core really needs to _ensure_ that network-manager-gnome is installed, other than upgrade issues without any other details. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Recommends for metapackages
Le mardi 10 juillet 2012 à 20:01 +0200, Jonas Smedegaard a écrit : I disagree: Looking at the many other dependencies of gnome-core, it clearly isn't meant as smallest possible GNOME setup but more essential parts of what the upstream GNOME project has to offer - as its package description also clearly reflects. When I want smallest possible GNOME setup i install gnome-session. Yes, maybe we should advertise it more, but gnome-session should be self-contained, and enough for a bare GNOME desktop without any applications. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1341998092.10559.132.camel@pi0307572
Re: Recommends for metapackages
On Mi, 11 iul 12, 11:14:52, Josselin Mouette wrote: Yes, maybe we should advertise it more, but gnome-session should be self-contained, and enough for a bare GNOME desktop without any applications. Yes please :) Some kind of harmonization of (meta-)package names with KDE would also be very nice. As far as I can tell, currently the equivalence would be: ??? kde-full gnome kde-standard gnome-core kde-plasma-desktop/kde-plasma-netbook gnome-session ??? (probably too late for wheezy, but maybe this could be done for wheezy+1) Thanks, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Recommends for metapackages
Le 11/07/12 11:14, Josselin Mouette a écrit : Le mardi 10 juillet 2012 à 20:01 +0200, Jonas Smedegaard a écrit : I disagree: Looking at the many other dependencies of gnome-core, it clearly isn't meant as smallest possible GNOME setup but more essential parts of what the upstream GNOME project has to offer - as its package description also clearly reflects. When I want smallest possible GNOME setup i install gnome-session. Yes, maybe we should advertise it more, but gnome-session should be self-contained, and enough for a bare GNOME desktop without any applications. Indeed, I think it would be good if the three meta-packages gnome, gnome-core and gnome-session would advertise each other in their long description. Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Recommends for metapackages
On 12-07-11 at 12:12pm, Andrei POPESCU wrote: On Mi, 11 iul 12, 10:55:16, Jonas Smedegaard wrote: The feature of _allowing a subset of packages to be removed that was _ensured_ to be installed: Impossible without defeating the feature of _ensuring_ those same package are installed. Agreed. However, unless I missed something I haven't seen any arguments for why gnome-core really needs to _ensure_ that network-manager-gnome is installed, other than upgrade issues without any other details. Package description isn't enough argument? This meta-package depends on a basic set of programs, including a file manager, an image viewer, a web browser, a video player and other tools. It contains the official “core” modules of the GNOME desktop. I still (as previously mentioned) believe that you really should focus on gnome-session instead, if you feel gnome-core is too invasive when it insist on installing certain image viewer, web browser, video player and other tools (which includes a certain network manager). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Recommends for metapackages
Andrei POPESCU andreimpope...@gmail.com wrote: ??? kde-full gnome kde-standard gnome-core kde-plasma-desktop/kde-plasma-netbook gnome-session ??? Maybe some sort of renaming would also be nice to make the ‘hierarchy’ more obvious? Along the lines of ??? kde-full *-full gnome kde-standard *-most gnome-core kde-plasma-desktop *-mini or *-small gnome-session ??? *-micro or *-minimal Everybody can see that micro mini and full *, but if you asked two people whether ‘core’ or ‘session’ were ‘larger’, you’d probably get three answers. The wording above is arguably improvable, though. Best regards thank you very much, Claudius -- 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/2012075530.23645...@ares.home.chubig.net
Re: Recommends for metapackages
On 2012-07-11, Andrei POPESCU andreimpope...@gmail.com wrote: --YZa61AII3s1sGKYx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mi, 11 iul 12, 11:14:52, Josselin Mouette wrote: =20 Yes, maybe we should advertise it more, but gnome-session should be self-contained, and enough for a bare GNOME desktop without any applications. Yes please :) Some kind of harmonization of (meta-)package names with KDE would also=20 be very nice. As far as I can tell, currently the equivalence would be: ??? kde-full gnome kde-standard gnome-core kde-plasma-desktop/kde-plasma-netbook gnome-session ??? I'd rather put kde-plasma-desktop/kde-plasma-netbook on the gnome-session level. and probably kde-full at the gnome level. kde-standard is not a collection by upstream, but a collection by the debian people, so it doesn't fully fit the gnome-core. /Sune -- 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/slrnjvqkm8.v2o.nos...@sshway.ssh.pusling.com
Re: Recommends for metapackages
On Tue, Jul 10, 2012 at 04:39:10PM +, Sune Vuorela wrote: On 2012-07-10, Gergely Nagy alger...@balabit.hu wrote: No. Only if installing recommends is turned on, which cannot be guaranteed. There is many ways to break your system. turning off installation of recommends is one of them. If turning off recommends leads to a broken system, then there's a serious bug somewhere, and it isn't the user. -- 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/20120711103854.GA11211@debian
Re: Recommends for metapackages
On Mi, 11 iul 12, 10:17:44, Sune Vuorela wrote: I'd rather put kde-plasma-desktop/kde-plasma-netbook on the gnome-session level. and probably kde-full at the gnome level. kde-standard is not a collection by upstream, but a collection by the debian people, so it doesn't fully fit the gnome-core. I went by package descriptions, the same as a (new) Debian user might do. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Recommends for metapackages
On Tue, 10 Jul 2012, Andrei POPESCU wrote: On Ma, 10 iul 12, 22:07:10, Eugene V. Lyubimkin wrote: ... And I disagree with that. No solution can override policy's all Depends must be satisfied. If one choose to support the exclude from metapackage one either has to change the policy, remove packages from Depends or use non-stock metapackage (which I personally don't like). One solution proposed some time ago was to have package managers mark packages depended on as manually installed, whenever the user choses to uninstall only one package depended by meta-pacakge. Wow, that'd be a very poor way to break the system further in order to make meta-packages even more annoying. IMO, metapackages should depend on the absolutely required stuff (and many times that will be the empty set), recommend the rest, and maybe even suggest fringe packages. This achieves maximum usability for more usecases, and malfunctions only in the unsupported case of no install recommends by default -- you should skip recommends always in a case-by-case basis. IMVHO Recommends makes more sense for packages that are not strictly required, but maybe package managers should gain a Install-New-Recommends option defaulting to true? Package managers already disclose that sort of relationship (sometimes indirectly). I've been using that information for years through aptitude. OTOH, metapackages from hell (like gnome or kde-full) based on Depends require me to select them, go to the will install these screen, deselect the meta package, and go over the list manually installing whatever isn't going to be useless/unwelcome for my specific case. And I will never notice if the metapackage changes its dependency tree later on. The only reason I have to do it in this extremely suboptiomal way, is the (IMO) abuse of Depends on metapackages instead of a much more proper mix of mostly recommends, with sparingly used depends and suggests when the situatuion warrants it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/2012074805.ga4...@khazad-dum.debian.net
Re: Recommends for metapackages
On Wed, 11 Jul 2012, Jon Dowland wrote: On Tue, Jul 10, 2012 at 04:39:10PM +, Sune Vuorela wrote: On 2012-07-10, Gergely Nagy alger...@balabit.hu wrote: No. Only if installing recommends is turned on, which cannot be guaranteed. There is many ways to break your system. turning off installation of recommends is one of them. If turning off recommends leads to a broken system, then there's a serious bug somewhere, and it isn't the user. Broken as in partially working because there are expected features missing is the _very_ definition of not installing a recommended package. Now, broken as in doesn't work at all for any use case would be a bug, yes. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/2012075132.gb4...@khazad-dum.debian.net
Re: Recommends for metapackages
On 11/07/2012 11:12, Andrei POPESCU wrote: On Mi, 11 iul 12, 10:55:16, Jonas Smedegaard wrote: The feature of _allowing a subset of packages to be removed that was _ensured_ to be installed: Impossible without defeating the feature of _ensuring_ those same package are installed. Agreed. However, unless I missed something I haven't seen any arguments for why gnome-core really needs to _ensure_ that network-manager-gnome is installed, other than upgrade issues without any other details. If my memory does not fail me, support from upstream (since network-manager is a core component of Gnome). I may be wrong. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Recommends for metapackages
On 2012-07-10 23:46, Jonathan Nieder wrote: - The gnome-core metapackage is very useful to some people. It helps people install a standard GNOME installation, keep it installed, and remove it later if they wish, using a single package. Most metapackages provide such a useful collection of packages (that may evolve over time). They usually provide alternative implementations of some functionality that don't conflict with each other (e.g. desktop environment: Gnome/KDE/Xfce/... (disregarding n-m for now), editor: vim/emacs/..., typesetting: texlive/libreoffice/...). Some have a subset relation: foo-core - foo-standard - foo-full If the metapackage depends on an application you don't like, you just don't use it and install another one. Usually the unused one won't do harm by just being installed. (If you were really concerned about disk space you wouldn't use the metapackages but install only the things you use (and create your own minimized metapackages).) The situation with n-m is a bit different: the functionality it provides *conflicts* with alternative solutions (which were previously enumerated in this thread) and there is (afaik) no switch to just turn n-m off to allow using $alternative while keeping n-m installed. - Some of the same people do not want to have network-manager installed. They also do not want to have network-manager fake-installed using equivs because they want to notice if they try to install something that actually requires network-manager. This functionality *conflict* is the reason several people (including me) would like to see that dependency downgraded to a Recommends. And if there are bugs in handling Recommends properly, they should be fixed. Andreas -- 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/4ffd7441.1040...@abeckmann.de
Re: Recommends for metapackages
On Wed, Jul 11, 2012 at 08:51:32AM -0300, Henrique de Moraes Holschuh wrote: Broken as in partially working because there are expected features missing is the _very_ definition of not installing a recommended package. Now, broken as in doesn't work at all for any use case would be a bug, yes. I don't disagree with you, and I think that this largely boils down to expectations management. Doesn't work at all is easier to define and agree upon than doesn't work as I expected, and I think maintainers have widely-differing interpretations of how to use Recommends: as a result. -- 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/20120711125013.GB11211@debian
Re: Recommends for metapackages
Eugene V. Lyubimkin jac...@debian.org writes: Moreover, despite me understanding the picture, I still has no clean, safe and documented way to do what I'd want in case the package maintainer chosed Depends. You have: install the pieces you want by hand. That's at least clean and safe. I do not think it is worth documenting explicitly. Using Recommends for non-core parts of metapackages' dependencies would nicely solve that. ...but I disagree that making meta-packages more elastic is a nice solution: is a hack covering over misguided users. Possible solutions could be improved documentation and improved design of package managers. ... And I disagree with that. No solution can override policy's all Depends must be satisfied. If one choose to support the exclude from metapackage one either has to change the policy, remove packages from Depends or use non-stock metapackage (which I personally don't like). Changing the policy would be stupid. Demoting to Recommends would be less so, but if upstream considers a package a core part of a platform, recommends *is* wrong. If you disagree with upstream, you have the tools and the ability to customize your system: use a non-stock meta package. It's not hard. I'd be very curious why you're so against it, perhaps we can come up with a solution that satisfies you? -- |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/874npexyso.fsf@algernon.balabit
Re: Recommends for metapackages
Henrique de Moraes Holschuh h...@debian.org writes: IMO, metapackages should depend on the absolutely required stuff (and many times that will be the empty set), recommend the rest, and maybe even suggest fringe packages. This achieves maximum usability for more usecases, and malfunctions only in the unsupported case of no install recommends by default -- you should skip recommends always in a case-by-case basis. That also achives maximum annoyance, because if I want the full platform, I'll have to go recommends/suggest hunting. (No, I'm *not* going to turn on install-recommends.) OTOH, metapackages from hell (like gnome or kde-full) based on Depends require me to select them, go to the will install these screen, deselect the meta package, and go over the list manually installing whatever isn't going to be useless/unwelcome for my specific case. And I will never notice if the metapackage changes its dependency tree later on. You could script all that, and keep your local list up-to-date with about ~10 minutes of work. -- |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/87zk76wk3o.fsf@algernon.balabit
Re: Recommends for metapackages
Andrei POPESCU andreimpope...@gmail.com writes: On Ma, 10 iul 12, 18:43:03, Gergely Nagy wrote: During the past ~14 years I've been using Debian with that setting turned off, nothing ever broke on my systems because of this setting. If it does, then I'll consider that a bug and report it appropriately. Depending on how you do the package selection on your next installation you might end up with rsyslog, but without logrotate[1]. I don't see how that would break anything. logrotate is not necessary for log rotation, not with the syslog daemon of my choice at least. And as you said yourself, log rotation isn't mandatory either. -- |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/87vchuwju9.fsf@algernon.balabit
Re: Recommends for metapackages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Le 11/07/12 14:36, Gergely Nagy a écrit : Henrique de Moraes Holschuh h...@debian.org writes: IMO, metapackages should depend on the absolutely required stuff (and many times that will be the empty set), recommend the rest, and maybe even suggest fringe packages. This achieves maximum usability for more usecases, and malfunctions only in the unsupported case of no install recommends by default -- you should skip recommends always in a case-by-case basis. Of course, there could be a network-manager-gui virtual package so that gnome-core can depend on network-manager-gui | network-manager-gnome. By the way, I find it enlightening to realize that gnome only recommends network-manager-gnome whereas gnome-core depends on it. That also achives maximum annoyance, because if I want the full platform, I'll have to go recommends/suggest hunting. (No, I'm *not* going to turn on install-recommends.) You don't want to turn on install-recommends, but you are happy with installing a loaded meta-package such as gnome or kde-full? I very much don't see the rationale behind this. This is what policy has to say about Recommends: The Recommends field should list packages that would be found together with this one in all but unusual installations. OTOH, metapackages from hell (like gnome or kde-full) based on Depends require me to select them, go to the will install these screen, deselect the meta package, and go over the list manually installing whatever isn't going to be useless/unwelcome for my specific case. And I will never notice if the metapackage changes its dependency tree later on. You could script all that, and keep your local list up-to-date with about ~10 minutes of work. The annoyance of not being able to uninstall just one of many packages pulled by a big meta-package does not affect only developers. A reasonable solution should be found which works for our priority: our users. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJP/XofAAoJEJOUU0jg3ChAhm0P/1oAp3bWqeJk66S5vDdHZdPk gKPNZf7h5qcg8ZPdNqmwTRVwmRYa8lrK8tMb1kILBjafhY/FOgRGs//phUN5tHts l28Yz7vlbRnC08ZbpfFW9msuYQ7XGVKROuY3ADnRxu5a9ilLivjNFT9btPsR26U7 /gFgIWYd+oXIdVCU4NYxoU68tY/IXnbheeQ7m5FkJd8I2d1e62eBvFFhrBpUFNwM tcWXJ6BTM13ymV8HIKv1cYgrGKV5nVYyiGvAoR1hnygOqdf4x4owUtdr7lcu9cPG TYiyH0MKmpATD1Vut1FWAHXfcEI4BP+7C8bm1h2pGlj8oBJHGl4Vt0J/fR3sqds8 qXWBVqjCUvVdB4z0LJ+VbT8osKRYUi3cmv/xeUo/nBGDkT8v6xGRsFLWh8aEhCcT kOawGqC6J82z63qjkTkSu7RswAKQBWatMMIwxWRmNYPoC8TZYi3zd4+WFcuOTi70 gM7QBmBNhl3eEfj7MQe9AlSAr824smDxel7tDoqNHNflfp5gShC/VuHJQP1JMinQ dNjATKBi1/EHZw7TBUfy0xXaOgfI3HmxSJMsrpgdJq360P/g8XKTl6fT1sLOxytC eLR8O/96zXRSX+pCkXpFiSke2pbnVidoXYbJwc6QV6KdncuSAj2ZHEJ3bIlhisOX /pALGJ09d5eCj/JREiXo =Bi/k -END PGP SIGNATURE- -- 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/4ffd7a20.2030...@users.sourceforge.net
Re: Recommends for metapackages
Noel David Torres Taño env...@rolamasao.org writes: Well, in case of GNOME, upstream considers n-m to be part of the core system, to the best of my knowledge. If upstream does so, so should we. No. That's why we have our own distribution instead of just a collection of unpatched packages compiled from source. Debian patches do not only include security or functionality bugs. They include also design bugs. Yet, we try to not diverge much from upstream, and maintain a good relationship with them. If they consider it core, so can we. Those who want to hand-pick parts of a meta package, can do so, we do not forbid. I do not see the problem: those who want the full platform, can get it easily. Those who don't, and want to exclude some, they can do so easily too. A bit more work, but hey, if you're going to cherry pick, that will always involve more work. The amount of extra work necessary is minimal though. -- |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/87r4siwjn4.fsf@algernon.balabit
Re: Recommends for metapackages
Thibaut Paumard paum...@users.sourceforge.net writes: That also achives maximum annoyance, because if I want the full platform, I'll have to go recommends/suggest hunting. (No, I'm *not* going to turn on install-recommends.) You don't want to turn on install-recommends, but you are happy with installing a loaded meta-package such as gnome or kde-full? I am happy with installing gnome, because I (or my parents, in case of my desktop) use pretty much all of it from time to time. Would I find something in it that I never use, and would it eat enough space or other resources to annoy me, I'd do my own local meta-package instead, that wouldn't have the unnecessary parts. The reason I do not turn on install-recommends, is because in the vast majority of cases, I do not need the recommended packages. Removing them by hand is much more work than installing the few that I do need. This isn't the case for the gnome meta-package. As for kde-full: no, I'd never install it. There's one kde thing I use, kcachegrind, and I'm happy to install that by hand. Would I be a kde user, I would probably not install kde-full either, because - by the looks of it - there would be significant parts of it that I'll never use. That doesn't mean it should only recommend them, no need to, I'm perfectly capable of installing the subset I need. I am also perfectly capable of writing a script to notify me whenever the meta-package's dependencys change, so I will have the option to pull in new things if I want to. (Said script is ~10 lines, and I wrote it yesterday in about 5 minutes; less time than I spent replying to this mail.) OTOH, metapackages from hell (like gnome or kde-full) based on Depends require me to select them, go to the will install these screen, deselect the meta package, and go over the list manually installing whatever isn't going to be useless/unwelcome for my specific case. And I will never notice if the metapackage changes its dependency tree later on. You could script all that, and keep your local list up-to-date with about ~10 minutes of work. The annoyance of not being able to uninstall just one of many packages pulled by a big meta-package does not affect only developers. A reasonable solution should be found which works for our priority: our users. Like I said earlier: script it. I posted a script that can remove any number of packages from another's depends line, and echo a control file. Updating that to create a local meta-package is a piece of cake. Hooking it into apt is also similarly easy, and bingo, you have a solution. Package it up, create a config file for it, and it's ready to be shipped to users. Everyone wins. The whole thing is about an hour of work with everything included for anyone who cares enough, far less than the time already spent arguing about silly things on this list. -- |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/87fw8ywhyf.fsf@algernon.balabit
Re: Recommends for metapackages
On 2012-07-11 14:33, Gergely Nagy wrote: Eugene V. Lyubimkin jac...@debian.org writes: Moreover, despite me understanding the picture, I still has no clean, safe and documented way to do what I'd want in case the package maintainer chosed Depends. You have: install the pieces you want by hand. That's at least clean and safe. I do not think it is worth documenting explicitly. No, this is (IMO) not a solution: [1] Using Recommends for non-core parts of metapackages' dependencies would nicely solve that. ...but I disagree that making meta-packages more elastic is a nice solution: is a hack covering over misguided users. Possible solutions could be improved documentation and improved design of package managers. ... And I disagree with that. No solution can override policy's all Depends must be satisfied. If one choose to support the exclude from metapackage one either has to change the policy, remove packages from Depends or use non-stock metapackage (which I personally don't like). [...] Demoting to Recommends would be less so, but if upstream considers a package a core part of a platform, recommends *is* wrong. If you disagree with upstream, you have the tools and the ability to customize your system: use a non-stock meta package. Well, disagreed here. By the logic above we, for example, cannot apply any patches NACKed by upstream. It's not hard. I'd be very curious why you're so against it, perhaps we can come up with a solution that satisfies you? Because if a user who installed Debian yesterday asks me So how do I do that? I want my answer to be It's easy, just do '$packagemanager remove $singlepackage' instead of It's easy, just build and maintain a non-stock meta package [1] a) and b) here: https://lists.debian.org/debian-devel/2012/07/msg00237.html -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux developer, Debian Developer -- 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/20120711153006.GB7554@r500-debian
Re: Re: Recommends for metapackages
By the way, I find it enlightening to realize that gnome only recommends network-manager-gnome whereas gnome-core depends on it. That was at gnome 2.30 times... -- 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/4ffd9de1.2060...@greffrath.com
Re: Recommends for metapackages
On Tue, 2012-07-10 at 20:01 +0200, Jonas Smedegaard wrote: On 12-07-10 at 06:34pm, Abou Al Montacir wrote: On Tue, 2012-07-10 at 18:10 +0200, Jonas Smedegaard wrote: The very purpose of a meta-package is to _ensure_ that a certain set of packages is installed, not just recommend them: All (not only most) users of that package need all its dependencies satisfied - those that don't should simply uninstall the meta-package. Exactly! And as confirmation see below you will see gnome recommending and even suggesting, which is probably fine: [lots of more or less unrelated package dependencies snipped] The most logical is that gnome-core does not depend on network-manager-gnome but the gnome package do. Indeed, experienced users will install gnome-core and select the rest manually. I disagree: Looking at the many other dependencies of gnome-core, it clearly isn't meant as smallest possible GNOME setup but more I never said that, I'm looking for a gnome installation with most of functionalities. I'm not interested in all functionalities. I'm not a Linux newbe but not also a gnome expert which knows what should be installed and what not. Typical use case is system administrator who have configured network using ifup/ifdown, needs to provide a working gnome for hist 1000 users, without having to figure out what they need and what they don't need. He don't want to learn how to use NM as his network configuration is working for more than 10 years. essential parts of what the upstream GNOME project has to offer - as its package description also clearly reflects. And NM is not essential in my point of view even if I don't see how I can do on my laptop without it and even if I love this package when I'm switching from WIFI access point to another, I find it absolutely not useful on a workstation with static IP and NFS (freezing the system each time NM tries to handle the connection). When I want smallest possible GNOME setup i install gnome-session As said before, I'm not looking for a minimal gnome, but for a typical gnome installation. I think this could be solved by relaxing dependency on gnome-core using a new gnome-laptop package which depends on NM even if I think that this is not mandatory: You just need to make gnome-core recommends gnome-network-manger gnome depends on gnome-network-manager I can argue that a network connection is not part of the core functionality as gnome could work perfectly without network connection. Cheers, signature.asc Description: This is a digitally signed message part
Re: Recommends for metapackages
Some argue that meta-packages can have a different purpose, and some argue that recommending also to some (lesser) extend ensures installation of packages. None of that, however, changes the fact that _this_ meta-package _now_ has the feature of strictly ensuring a certain set of packages. For those wanting that. And not for those feeling it is in their way, but those can simply avoid that package: A meta-package has no functionalirty beyond pulling in packages, so there is no loss to the resulting system other than lack of its sole feature. Error. A meta-package has functionality way beyond that. It exists not only to pull in packages, but also to allow auto removal of leaf packages when the admin decides to get rid of them, to maintain a collection of related packages together, to avoid deinstallations when upgrading libraries (aptitude has the insane actitude of proposing removal of tons of packages before proposing upgrading une of them, and if you see your loved metapackage in the list you know something is wrong with the option and press . ), pulling new software in when the collection changes, etc. So a meta-package is just a way of installing things together, and a lot more. But from those things, only dependencies should be Depends, and software that improves the collection should be Recommends. In this particular case, N- M improves gnome but it is not needed at all. Think on this use case: a user wants a full gnome installation and to be able to get new versions of programs (or even new substitute programs) to be automatically installed when they change on the 'gnome' package, but also wants pidgin and evolution work online while he has a static interface (not managed by n-m). This user can fill a bug against gnome-core due that it forces him to install a package that breaks the functionality of pidgin on his system. And he is right. Regards Noel Torres er Envite signature.asc Description: This is a digitally signed message part.
Re: Recommends for metapackages
I still (as previously mentioned) believe that you really should focus on gnome-session instead, if you feel gnome-core is too invasive when it insist on installing certain image viewer, web browser, video player and other tools (which includes a certain network manager). Installing an image viewer, a web browser or a video player does not break functionality of unrelated software, just gives you more options. Installing N-M breaks unrelated software. Regards Noel Torres er Envite signature.asc Description: This is a digitally signed message part.
Re: Recommends for metapackages
Yet, we try to not diverge much from upstream, and maintain a good relationship with them. If they consider it core, so can we. Those who want to hand-pick parts of a meta package, can do so, we do not forbid. If we want to be user friendly, it is not a matter of we do not forbid, it is a matter of we make easy. Besides, low-level users will install Recommends by default, so they will get the whole box anyway. But medium or high level users may probably want N-M not to mess their network EVEN if they want the whole gnome desktop set. I do not see the problem: those who want the full platform, can get it easily. Those who don't, and want to exclude some, they can do so easily too. A bit more work, but hey, if you're going to cherry pick, that will always involve more work. The amount of extra work necessary is minimal though. Not so minimal if you want your gnome set to be up to date, including new applications being installed. What we should do is to allow TWO levels of cherry-picking: the one for advanced users who want to individually select every package, and the other for users who want the whole set without a specific, molesting package. If that package is not a true dependency of the core of the set, Recommends is more than justified. Regards Noel Torres er Envite signature.asc Description: This is a digitally signed message part.
Re: Recommends for metapackages
On Wed, 11 Jul 2012, Gergely Nagy wrote: Henrique de Moraes Holschuh h...@debian.org writes: IMO, metapackages should depend on the absolutely required stuff (and many times that will be the empty set), recommend the rest, and maybe even suggest fringe packages. This achieves maximum usability for more usecases, and malfunctions only in the unsupported case of no install recommends by default -- you should skip recommends always in a case-by-case basis. That also achives maximum annoyance, because if I want the full platform, I'll have to go recommends/suggest hunting. (No, I'm *not* going to turn on install-recommends.) You're not using the recommended behaviour which exists for extremely good reasons (_and_ it is the default almost every user will use, mandated and backed by policy for years). That gives you the extra responsibility of not missing any recommended package that you should have installed. I am extremely unimpressed. While I commend you in being one of the guinea pigs that will be hit first when someone misclassifies a dependency as recommends instead of depends and I recognize the importance of that job, I fell that is hardly a good reason to push against better metapackages that would make them actually useful for a much larger set of people[1]. I routinely skip installing recommended packages, but I take that decision in a case-by-case basis. Unlike you, I am not pushing on the majority an inferior, sub-optimal behaviour which I'd not be willing to deal with myself. I *already* deal with the resulting sub-optimal behaviour of metapackages abusing depends. [1] As in people complaining in debian-user that: package manager wants to remove my entire desktop environment when the user tries to install a package that conflicts with something depended by a metapackage. OTOH, metapackages from hell (like gnome or kde-full) based on Depends require me to select them, go to the will install these screen, deselect the meta package, and go over the list manually installing whatever isn't going to be useless/unwelcome for my specific case. And I will never notice if the metapackage changes its dependency tree later on. You could script all that, and keep your local list up-to-date with about ~10 minutes of work. So could you. The difference is that you'd be doing it because you're running with your package manager configured for behaviour opposite to the recommended one that all regular users and most DDs do. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/20120711183131.ge4...@khazad-dum.debian.net
Re: Recommends for metapackages
On 12-07-11 at 07:54pm, Abou Al Montacir wrote: On Tue, 2012-07-10 at 20:01 +0200, Jonas Smedegaard wrote: essential parts of what the upstream GNOME project has to offer - as its package description also clearly reflects. And NM is not essential in my point of view Your view is irrelevant here: GNOME project considers it essential. When I want smallest possible GNOME setup i install gnome-session As said before, I'm not looking for a minimal gnome, but for a typical gnome installation. No, you are looking for an *atypical* installation, want Debian to provide a meta-package that fits your needs. Sorry, but Debian only provides meta-packages for typical needs. And only for *some* typical needs. Debian can be very flexible - just install normal packages. But you want something simpler. Debian can be very simple - just install meta-packages. But you want something more customized. *sigh* I can argue that a network connection is not part of the core functionality as gnome could work perfectly without network connection. You can, and you do, but gnome-core is not about core functionality. Read the package description for an explanation of what the package is about! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Recommends for metapackages
On 12-07-11 at 07:21pm, Noel David Torres Taño wrote: I still (as previously mentioned) believe that you really should focus on gnome-session instead, if you feel gnome-core is too invasive when it insist on installing certain image viewer, web browser, video player and other tools (which includes a certain network manager). Installing an image viewer, a web browser or a video player does not break functionality of unrelated software, just gives you more options. Installing N-M breaks unrelated software. That is a bug in network-manager, not in gnome-core. That bug is not fixed nor worked around by making it easier to avoid the broken package. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Recommends for metapackages
Gergely wrote: Henrique de Moraes Holschuh h...@debian.org writes: IMO, metapackages should depend on the absolutely required stuff (and many times that will be the empty set), recommend the rest, and maybe even suggest fringe packages. This achieves maximum usability for more usecases, and malfunctions only in the unsupported case of no install recommends by default -- you should skip recommends always in a case-by-case basis. That also achives maximum annoyance, because if I want the full platform, I'll have to go recommends/suggest hunting. (No, I'm *not* going to turn on install-recommends.) Right. So you're arguing that all the packages should be listed as Depends: to make *your* life easier, when you're doing something different from what's recommended. Thanks for showing how much weight we should attach to your argument. -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- 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/e1sp3l1-0004mw...@mail.einval.com
Re: Recommends for metapackages
On Mi, 11 iul 12, 15:22:32, Gergely Nagy wrote: Like I said earlier: script it. I posted a script that can remove any number of packages from another's depends line, and echo a control file. Updating that to create a local meta-package is a piece of cake. Hooking it into apt is also similarly easy, and bingo, you have a solution. Package it up, create a config file for it, and it's ready to be shipped to users. Everyone wins. IMVHO the defaults should be chosen to be friendly to potentially not so knowledgeable users. Using Recommends instead of Depends in metapackages would be much more friendly to them, while a more knowledgeable user can always just use --install-recommends/--with-recommends if they are disabled. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Recommends for metapackages
On Mi, 11 iul 12, 14:41:50, Gergely Nagy wrote: Andrei POPESCU andreimpope...@gmail.com writes: Depending on how you do the package selection on your next installation you might end up with rsyslog, but without logrotate[1]. I don't see how that would break anything. logrotate is not necessary for log rotation, not with the syslog daemon of my choice at least. And as you said yourself, log rotation isn't mandatory either. Given that I have turned off Recommends on that system because it's space constrained (it's running from a 2GB USB stick) having logs not rotated would have become a problem eventually. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Recommends for metapackages
Installing N-M breaks unrelated software. That is a bug in network-manager, not in gnome-core. That bug is not fixed nor worked around by making it easier to avoid the broken package. No. It is not a broken package. It does what it is designed to do. The bug is having it as a Depends when it is not a dependency. The solution is having it as a Recommends. This will work for most users (since most users install Recommends by default), while giving FREEDOM OF CHOICE for those who are expertised enough to decide if installing Recommends or not. Everything else (like not installing the metapackage and cherrypicking packages, creating ad-hoc metapackage or scripting) are workarounds. Removing it by hand with dpkg -P --force-depends is an uglier workaround, and the only one available to people without expertise programming/packaging/hunting cherries. Regards Noel Torres er Envite signature.asc Description: This is a digitally signed message part.
Re: Recommends for metapackages
[...] essential parts of what the upstream GNOME project has to offer - as its package description also clearly reflects. And NM is not essential in my point of view Your view is irrelevant here: GNOME project considers it essential. Gnome view is the one irrelevant. This is Debian GNU/Linux, not Gnome GNU/Linux. We need to care for our users (both proficient and novice [1]), not for Gnome developers desires. And if they had a flawed design we can patch, we should do as we do with any other flawed software. [...] As said before, I'm not looking for a minimal gnome, but for a typical gnome installation. No, you are looking for an *atypical* installation, want Debian to provide a meta-package that fits your needs. What is typical is a user who install Recommends by default, so that user will have the same packages if he installs a gnome-core with n-m as Recommends as if he install a gnome-core with n-m as Depends. And since typical users will receive the same packages, we can care for not- so-typical users and do The Correct Thing: have n-m as a Recommend. The Policy reads about Recommends, very clearly, that it is to be used for packages to be found on all but rare installations. Let's obey the Policy. [1] Proficent users may want to install gnome easyly, but not to have n-m as it will probably break their systems or just make their Pidgin not to work properly. This can be achieved by having n-m as a Recommends. Novice users want to install gnome easyly and to manage ther network easyly, and also to manage their packages easyly, and that means installing metapackages and having these pulling in Recommends by default. So both kinds of users will benefit by having n-m as a Recommend. Only angry users would be a) Gnome developers/fanboys, and b)...well, there is no b). Regards Noel Torres er Envite signature.asc Description: This is a digitally signed message part.
Re: Recommends for metapackages
Noel David Torres Taño env...@rolamasao.org (11/07/2012): Your view is irrelevant here: GNOME project considers it essential. Gnome view is the one irrelevant. This is Debian GNU/Linux, not Gnome GNU/Linux. We need to care for our users (both proficient and novice [1]), not for Gnome developers desires. And if they had a flawed design we can patch, we should do as we do with any other flawed software. Blah blah blah. What matters is the maintainers' views (as long as common sense applies). They chose to follow upstream's choices, which is usually a sane thing to do (unless upstream is crazy). Now if you don't like those choices, pick your own packages yourself, build your own meta package, or whatever. Plenty of RC bugs to submit patches for. Surely more interesting than those meta packages, right? Mraw, KiBi. signature.asc Description: Digital signature
Re: Recommends for metapackages
On July 10, 2012 10:39:10 AM Sune Vuorela wrote: On 2012-07-10, Gergely Nagy alger...@balabit.hu wrote: No. Only if installing recommends is turned on, which cannot be guaranteed. There is many ways to break your system. turning off installation of recommends is one of them. So, if Recommends should always be installed--effectively turning them into Depends--why do Recommends exist... Not installing a Recommended package shouldn't break your system, functionality will be reduced but if it breaks then the package probably should be Depended upon or split into depended and recommended upon parts. - Bruce -- 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/201207111652.27393.bms...@shaw.ca
Re: Recommends for metapackages
On 2012-07-11, Bruce Sass bms...@shaw.ca wrote: On July 10, 2012 10:39:10 AM Sune Vuorela wrote: On 2012-07-10, Gergely Nagy alger...@balabit.hu wrote: No. Only if installing recommends is turned on, which cannot be guaranteed. There is many ways to break your system. turning off installation of recommends is one of them. So, if Recommends should always be installed--effectively turning them into Depends--why do Recommends exist... for the 1-2% of people who has weird needs. and it is okay to have weird needs. bug reports just needs to also come with a patch. /Sune -- 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/slrnjvs2qh.7kg.nos...@sshway.ssh.pusling.com
Re: Recommends for metapackages
On 11 July 2012 14:21, Noel David Torres Taño env...@rolamasao.org wrote: Installing N-M breaks unrelated software. Hi! I don't claim to be a networking expert, but I believe half the conversation here is based on wrong or outdated information. I encourage those who think NetworkManager (NM) doesn't play well with ifup/ifdown to please read http://wiki.debian.org/NetworkManager#NetworkManager_in_Squeeze Furthermore, not having NM running breaks the Network panel in System Settings (gnome-control-center). NetworkManager makes connecting to WiFi points much much easier, while at the same time NOT breaking wired connectivity. Oh, and NM works just fine for USB tethering with my Android phone too. GNOME considers NM to be part of GNOME Core, therefore gnome-core depends on it. If you're allergic to NM, either don't install gnome-core; let NM install but tell it never to run; or follow one of the several workarounds already posted to this list. Thanks, Jeremy -- 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/caaajcmzvrd2m1riqq51pxpca0zuey-eluvchczqt0mmzrw3...@mail.gmail.com
Re: Recommends for metapackages
On Wed, Jul 11, 2012 at 08:04:18PM -0400, Jeremy Bicha wrote: On 11 July 2012 14:21, Noel David Torres Taño env...@rolamasao.org wrote: Installing N-M breaks unrelated software. I don't claim to be a networking expert, but I believe half the conversation here is based on wrong or outdated information. I encourage those who think NetworkManager (NM) doesn't play well with ifup/ifdown to please read http://wiki.debian.org/NetworkManager#NetworkManager_in_Squeeze The information on that page is outdated, then. On my system for example, it shows eth0 as unmanaged (correctly) but puts its grubby mitts into br0 and usb0, both of which are listed in /etc/network/interfaces. Being unmanaged also makes it think the interface is down. Also, the page you linked to includes this line: # understand that NetworkManager is not intended to serve the needs of all # users So if n-m is not supposed to be universal, it must not prevent people from doing things not supported by it, either by standing aside or being uninstallable. Furthermore, not having NM running breaks the Network panel in System Settings (gnome-control-center). It makes it give an error message. This is the only regression, and it really should check the presence of NM instead of blindly show that icon. Even then, it's not a show stopping bug. And getting rid of a non-functional icon from the systray is worth having another in some section of a settings panel (even if I'd prefer having neither). NetworkManager makes connecting to WiFi points much much easier Which is related to it messing with interfaces other than WiFi... how? while at the same time NOT breaking wired connectivity. We wouldn't have this long thread if it indeed did not break it. Oh, and NM works just fine for USB tethering with my Android phone too. Not for mine (N900) nor my brother's (some Android, can't check until he visits again). NM recognizes it as Nokia N900 but tries to configure it despite being told not to, and it keeps resetting it every a few seconds so you can't fix it up manually. GNOME considers NM to be part of GNOME Core, therefore gnome-core depends on it. It also wants systemd and mono, yet on Debian you can install without either. If you're allergic to NM, either don't install gnome-core; Gnome has enough components to make installing it without help of meta packages an unreasonable idea for anyone not deeply involved with Gnome development. And we're talking about -core not all bells and whistles. let NM install but tell it never to run The last time I tried, /etc/resolv.conf became: # Generated by NetworkManager\n\n. This is also inventing a way around dependencies: if a daemon is not supposed to be ever run, it shouldn't be installed in the first place, otherwise the packaging system has no way to specify actual requirements. or follow one of the several workarounds already posted to this list. You mean, using dpkg --force-depends and not using apt at all? Or making my own equivs metapackage (which I can do but most users can't)? -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 signature.asc Description: Digital signature
Re: Recommends for metapackages
On Wed, Jul 11, 2012 at 07:21:00PM +0100, Noel David Torres Taño wrote: Installing N-M breaks unrelated software. No. At most it breaks *related* software. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Recommends for metapackages
On Wed, Jul 11, 2012 at 09:32:19PM -0600, Philipp Kern wrote: On Wed, Jul 11, 2012 at 07:21:00PM +0100, Noel David Torres Taño wrote: Installing N-M breaks unrelated software. No. At most it breaks *related* software. Exactly, that's why it's the gnome-core package that's RC-buggy, not network-manager. Unless someone thinks a desktop environment's core function is to mess with the network, that is. -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 signature.asc Description: Digital signature
Re: Recommends for metapackages
Eugene V. Lyubimkin jac...@debian.org writes: On 2012-07-10 15:32, Josselin Mouette wrote: Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : What's wrong with Recommends: in that case? It seems to perfectly match the makes life easier for common but not universal use-case XXX scenario you describe. Recommends is wrong for metapackages because it gets upgrades very wrong. This is why it is used very marginally. Standards should not depend on implementation details. I see zero reasons why metapackages are (or should be) specific here. Whatever $it that gets upgrades wrong should be fixed instead. But the purpose of the meta-package is to pull stuff in. Depends does that, Recommends does not, therefore Recommends is not appropriate for the task. For the cases where one wants to have most of the stuff installed that the meta-package would pull in, but not all, solutions already exist. And like Josselin said in the same mail, there is a large overlap between those who want to push some of the stuff in Depends to Recommends, and those who can just make their own local meta-package within 5 minutes and be done with it. -- |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/87obnnzoly.fsf@algernon.balabit
Re: Recommends for metapackages
On 2012-07-10 16:18, Gergely Nagy wrote: But the purpose of the meta-package is to pull stuff in. Depends does that, Recommends does not, therefore Recommends is not appropriate for the task. Surely Recommends does pull stuff in. It's clearly reflected in Debian policy and supported by most if not all high-level packages managers in Debian. Therefore it's totally appropriate for the task. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux developer, Debian Developer -- 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/20120710151412.GB5107@r500-debian
Re: Recommends for metapackages
On 12-07-10 at 06:14pm, Eugene V. Lyubimkin wrote: On 2012-07-10 16:18, Gergely Nagy wrote: But the purpose of the meta-package is to pull stuff in. Depends does that, Recommends does not, therefore Recommends is not appropriate for the task. Surely Recommends does pull stuff in. It's clearly reflected in Debian policy and supported by most if not all high-level packages managers in Debian. Therefore it's totally appropriate for the task. Recommends does not _ensure_ that all is pulled in. The very purpose of a meta-package is to _ensure_ that a certain set of packages is installed, not just recommend them: All (not only most) users of that package need all its dependencies satisfied - those that don't should simply uninstall the meta-package. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Recommends for metapackages
On 2012-07-10 18:10, Jonas Smedegaard wrote: The very purpose of a meta-package is to _ensure_ that a certain set of packages is installed, not just recommend them: All (not only most) users of that package need all its dependencies satisfied My definition of meta-package is less strict than yours. I as user sometimes want '[meta]package X, but without packages Y and Z', and your definition absolutely rules that out. I saw many questions on forums like I did '$packagemanager install $metapackage' and then after '$packagemanager remove $singlepackage', why $packagemanager now wants to remove all $metapackage? , so I know I'm not alone. Using Recommends for non-core parts of metapackages' dependencies would nicely solve that. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux developer, Debian Developer -- 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/20120710163528.GC5107@r500-debian
Re: Recommends for metapackages
On Tue, 2012-07-10 at 18:10 +0200, Jonas Smedegaard wrote: On 12-07-10 at 06:14pm, Eugene V. Lyubimkin wrote: On 2012-07-10 16:18, Gergely Nagy wrote: But the purpose of the meta-package is to pull stuff in. Depends does that, Recommends does not, therefore Recommends is not appropriate for the task. Surely Recommends does pull stuff in. It's clearly reflected in Debian policy and supported by most if not all high-level packages managers in Debian. Therefore it's totally appropriate for the task. Recommends does not _ensure_ that all is pulled in. The very purpose of a meta-package is to _ensure_ that a certain set of packages is installed, not just recommend them: All (not only most) users of that package need all its dependencies satisfied - those that don't should simply uninstall the meta-package. Exactly! And as confirmation see below you will see gnome recommending and even suggesting, which is probably fine: aptitude show gnome Package: gnome State: installed Automatically installed: yes Version: 1:3.0+9 Priority: optional Section: gnome Maintainer: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org Architecture: i386 Uncompressed Size: 52.2 k Depends: gnome-core (= 1:3.0+9), desktop-base, alacarte (= 0.13.2), cheese (= 3.0), ekiga (= 3.2), evolution (= 3.0), evolution-plugins (= 3.0), file-roller (= 3.0), gedit (= 3.0), gnome-documents, gnome-games (= 1:3.0), gnome-orca (= 3.2), gnome-nettool (= 3.0), hamster-applet (= 2.91.2), seahorse (= 3.0), tomboy (= 1.6) | gnote, vinagre (= 3.0), abiword (= 2.8) | libreoffice-gnome, avahi-daemon, gimp (= 2.6), gnome-media (= 2.91), gnumeric (= 1.10) | libreoffice-gnome, inkscape (= 0.48), rhythmbox (= 2.90), shotwell, simple-scan, sound-juicer (= 2.32.1+20110330), transmission-gtk, xdg-user-dirs-gtk, libatk-adaptor, cups-pk-helper (= 0.1.2), epiphany-extensions (= 3.0), gedit-plugins (= 3.0), gnome-applets (= 2.91), gstreamer0.10-ffmpeg (= 0.10.12), gstreamer0.10-plugins-ugly (= 0.10.18), gvfs-bin, nautilus-sendto (= 3.0), rhythmbox-plugins, rhythmbox-plugin-cdrecorder, telepathy-gabble, telepathy-salut, totem-plugins, libgtk2-perl (= 1:1.130) Recommends: browser-plugin-gnash, gdebi, gnome-games-extra-data (= 3.0), liferea | evolution-rss | blam, menu-xdg, nautilus-sendto-empathy, telepathy-idle Suggests: dia-gnome, gnucash, libreoffice-gnome, libreoffice-evolution, planner, gnome-tweak-tool saida:~# aptitude show gnome-core Package: gnome-core State: installed Automatically installed: yes Version: 1:3.0+9 Priority: optional Section: gnome Maintainer: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org Architecture: i386 Uncompressed Size: 52.2 k Depends: brasero (= 3.0), dconf-gsettings-backend (= 0.7.5), dconf-tools (= 0.7.5), empathy (= 3.0), eog (= 3.0), epiphany-browser (= 3.0), evince (= 3.0), evolution-data-server (= 3.0), fonts-cantarell, sound-theme-freedesktop, gcalctool (= 6.0), gconf2 (= 2.32), gdm3 (= 3.0), glib-networking (= 2.28.7), gnome-backgrounds (= 3.0), gnome-bluetooth (= 3.0), gnome-contacts, gnome-control-center (= 1:3.0), gnome-disk-utility (= 3.0), gnome-icon-theme (= 3.0), gnome-icon-theme-extras (= 3.0), gnome-icon-theme-symbolic (= 3.0), gnome-keyring (= 3.0), libpam-gnome-keyring (= 3.0), gnome-menus (= 3.0), gnome-packagekit (= 3.0), gnome-panel (= 3.0), gnome-power-manager (= 3.0), gnome-screensaver (= 3.0), gnome-session (= 3.0), gnome-session-fallback (= 3.0), gnome-settings-daemon (= 3.0), gnome-shell (= 3.0), gnome-system-monitor (= 3.0), gnome-terminal (= 3.0), gnome-themes-standard (= 3.0), gnome-user-guide (= 3.0), gnome-user-share (= 3.0), baobab (= 3.0), gnome-dictionary (= 3.0), gnome-screenshot (= 3.0), gnome-search-tool | tracker-gui, gnome-system-log (= 3.0), gnome-font-viewer (= 3.0), gsettings-desktop-schemas (= 3.0), gstreamer0.10-plugins-base (= 0.10.34), gstreamer0.10-plugins-good (= 0.10.29), gstreamer0.10-pulseaudio (= 0.10.29), libgail-3-common (= 3.0) | libgtk-3-common (= 3.2), gucharmap (= 1:3.0), gvfs-backends (= 1.8), libcanberra-pulse, metacity (= 1:2.34), nautilus (= 3.0), network-manager-gnome (= 0.9), notification-daemon (= 0.7), policykit-1-gnome, pulseaudio, totem (= 3.0), vino (= 3.0), yelp (= 3.0), zenity (= 3.0) Suggests: gnome Description: The GNOME Desktop Environment -- essential components The most logical is that gnome-core does not depend on network-manager-gnome but the gnome package do. Indeed, experienced users will install gnome-core and select the rest manually. signature.asc Description: This is a digitally signed message part
Re: Recommends for metapackages
Eugene V. Lyubimkin jac...@debian.org writes:
On 2012-07-10 16:18, Gergely Nagy wrote:
But the purpose of the meta-package is to pull stuff in. Depends does
that, Recommends does not, therefore Recommends is not appropriate for
the task.
Surely Recommends does pull stuff in.
No. Only if installing recommends is turned on, which cannot be
guaranteed.
It's clearly reflected in Debian policy
No, it is not.
Recommends
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found together
with this one in all but unusual installations.
Nowhere does that say that whatever is in recommends, will be
installed. Therefore, tools will *not* pull those in, unless they are
asked to.
and supported by most if not all high-level packages managers in
Debian.
Yes, apt and aptitude supports Apt::Install-Recommends, and it is
enabled by default. But it can - and often is - turned off.
Therefore it's totally appropriate for the task.
It is not, because the purpose of the meta package is to get things
installed *always*. If it would be an optional collection of stuff, it
wouldn't be a meta package.
But, to cut the story short, attached to this mail is a script you can
use to take any metapackage, and remove (or demote) any of its
dependencies. It echoes a control-file thingy, combining it with equivs
is left as an excercise to the reader.
Usage:
$ ./meta-gen.sh gnome-core network-manager-gnome
Build a local package out of that, use happily ever after. Our
meta-packages can continue depending on what upstream considers part of
a package suite, and those of you who want to have most, but not all of
it, can use the script to create a local meta package. Since it's
scripted, you can even keep the local thing reasonably up to date.
It took about ~5 minutes to write that script, would take another 10 or
so to make it build a local package too. I'm fairly sure this could be
hooked into apt via a Apt::Update::Post-Invoke: once apt-get update ran,
update the local meta packages, push it to a local repo, touch a stamp
file, and update again. But perhaps there's even a way to make this play
nicer, I didn't care that much.
Crude, but should work, with about ~20 minutes of total time spent on
it. Much less than pointless arguing on a list about something that's so
very easy to solve in a way that everyone wins.
--
|8]
#! /bin/sh
set -e
pkg=$1
shift
dropdeps=,$(echo $@ | sed -e 's# #,#g'),
if [ -z ${pkg} ]; then
cat EOF
Usage: $0 meta-package dependencies-to-drop...
EOF
exit 1
fi
_deps=$(grep-aptavail -X -sDepends -n -P ${pkg})
OLD_IFS=${IFS}
IFS=,
_newdeps=
for dep in $_deps; do
d=$(echo ${dep} | sed -e s,^ *,, -e s,[ \(].*,,)
case $dropdeps in
*,$d,*)
;;
*)
_newdeps=${_newdeps}${dep},
;;
esac
done
IFS=${OLD_IFS}
_newdeps=$(echo $_newdeps | sed -e 's#, *$##')
grep-aptavail -X -P ${pkg} | sed -e s#^Depends:.*#Depends: $_newdeps#
