[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-11 14:33, Gergely Nagy wrote:
>> "Eugene V. Lyubimkin" <jackyf@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:

>> [...] 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

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


Reply to: