FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-13-2012, 11:12 PM
Roger Lynn
 
Default Recommends for metapackages

[sorry for the lengthy quoting below]
On 12/07/12 10:10, Gergely Nagy wrote:
> Noel David Torres Tao <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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: njm6d9-ji2.ln1@silverstone.rilynn.me.uk">http://lists.debian.org/njm6d9-ji2.ln1@silverstone.rilynn.me.uk
 
Old 07-14-2012, 08:59 PM
Tollef Fog Heen
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87a9z2awjs.fsf@vuizook.err.no">http://lists.debian.org/87a9z2awjs.fsf@vuizook.err.no
 
Old 07-31-2012, 07:40 AM
Bjrn Mork
 
Default Recommends for metapackages

Jean-Christophe Dubacq <jcdubacq1@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.


Bjrn


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87hasonzt2.fsf@nemi.mork.no">http://lists.debian.org/87hasonzt2.fsf@nemi.mork.no
 

Thread Tools




All times are GMT. The time now is 05:16 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org