Re: Recommends for metapackages
[sorry for the lengthy quoting below]
On 12/07/12 10:10, Gergely Nagy wrote:
> Noel David Torres Taño <envite@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
Reply to: