|
[...] > >> 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 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.
It is not a mater of wanting "some little things". It is a matter of wanting the whole thing except a piece that messes the system configuration. > > 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.
Having it as a Recommends still pulls it together for most users, those who do not need it removed. Not so hard to understand. But for those users who a) do not want (or even can not have) N-M and b) are not developers, those you provided are not solutions. > > You're welcome.
Same :)
Regards Noel Torres er Envite |
Attachment:
signature.asc
Description: This is a digitally signed message part.