[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Recommends for metapackages



"Eugene V. Lyubimkin" <jackyf@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#"

Reply to: