Re: Recommends for metapackages

2012-07-12 Thread Josselin Mouette 
Le mercredi 11 juillet 2012 à 19:17 +0100, Noel David Torres Taño a
écrit :
> So a meta-package is "just" a way of installing things together, and a
> lot more. But from those things, only dependencies should be Depends,
> and software that improves the collection should be Recommends. In
> this particular case, N-M improves gnome but it is not needed at all.

By the same view, totem improves GNOME, but it is not needed at all.
Gcalctool improves GNOME, but it is not needed at all.
Here’s the point: those packages are *part* of GNOME.  And that includes
nm-gnome, too.

If you want only the required components, install gnome-session.
Everything else is “improvement”.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1342077817.10559.183.camel@pi0307572

Re: Recommends for metapackages

2012-07-12 Thread Andreas Beckmann 
On 2012-07-12 09:23, Josselin Mouette wrote:
> By the same view, totem improves GNOME, but it is not needed at all.

Correct. But it does not conflict with kaffeine, mplayer, vlc, xine, ...

> Gcalctool improves GNOME, but it is not needed at all.

Correct. But it does not conflict with bc, kcalc, ...

> Here’s the point: those packages are *part* of GNOME.  And that includes
> nm-gnome, too.

But it does *conflict* with the alternatives.

Debian's horizon extends far beyond 'just Gnome'.


Andreas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffe8397.1090...@abeckmann.de

Bug#681298: ITP: font-kalapi -- Kalapi Gujarati Unicode font

2012-07-12 Thread Kartik Mistry 
Package: wnpp
Severity: wishlist
Owner: Debian-IN Team 

* Package name: font-kalapi
  Version : 0.1
  Upstream Author : GujaratiLexicon Team 
* URL : https://github.com/gujaratilexicon/font-kalapi
* License : OFL-1.1
  Programming Lang: N/A
  Description : Kalapi Gujarati Unicode font

Kalapi Unicode font for Gujarati (gu) language.

--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: Digital signature

Re: Recommends for metapackages

2012-07-12 Thread Abou Al Montacir 
On Wed, 2012-07-11 at 23:57 +0200, Cyril Brulebois wrote:
> Noel David Torres Taño  (11/07/2012):
> > > Your view is irrelevant here: GNOME project considers it essential.
> > 
> > Gnome view is the one irrelevant. This is Debian GNU/Linux, not Gnome
> > GNU/Linux. We need to care for our users (both proficient and novice [1]),
> > not for Gnome developers desires. And if they had a flawed design we can
> > patch, we should do as we do with any other flawed software.
> 
> Blah blah blah. What matters is the maintainers' views (as long as
> common sense applies). They chose to follow upstream's choices, which is
> usually a sane thing to do (unless upstream is crazy).
If Gnome core are really convinced that NM is essential, why Gnome could
be run without NM? Why not all Gnome applications are depending on NM
for network detection? Why the applications that depends on NM like
evolution have all a fall-back mode?

I'm maintaining a package which upstream delivers as all in one (600MB)
and refuses to support splitting. I've split it into 22 packages because
I know and got requests from users who want to have it in machines with
small disks and/or low internet.
Upstream never accepted that, but I didn't gave up, because what matters
for me is user not upstream

> Now if you don't like those choices, pick your own packages yourself,
> build your own meta package, or whatever.
An push it to repository? Then Yes I can upload a
gnome-desktop-workstation package to be used for atypical users like me

> Plenty of RC bugs to submit patches for. Surely more interesting than
> those meta packages, right?
I'm not interested in patching Gnome myself, I'm a user, not a gnome
maintainer/developer

Cheers,


signature.asc
Description: This is a digitally signed message part

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
Noel David Torres Taño  writes:

>> Yet, we try to not diverge much from upstream, and maintain a good
>> relationship with them. If they consider it core, so can we. Those who
>> want to hand-pick parts of a meta package, can do so, we do not forbid.
>
> If we want to be user friendly, it is not a matter of "we do not forbid", it 
> is a matter of "we make easy". Besides, low-level users will install 
> Recommends by default, so they will get the whole box anyway. But medium or 
> high level users may probably want N-M not to mess their network EVEN if they 
> want the whole gnome desktop set.
>> 
>> I do not see the problem: those who want the full platform, can get it
>> easily. Those who don't, and want to exclude some, they can do so easily
>> too. A bit more work, but hey, if you're going to cherry pick, that will
>> always involve more work.
>> 
>> 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 < 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.

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

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.

You're welcome.

-- 
|8]


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hatdv0dm.fsf@algernon.balabit

Re: Recommends for metapackages

2012-07-12 Thread Jonas Smedegaard 
On 12-07-12 at 10:28am, Abou Al Montacir wrote:
> I'm maintaining a package which upstream delivers as all in one 
> (600MB) and refuses to support splitting. I've split it into 22 
> packages because I know and got requests from users who want to have 
> it in machines with small disks and/or low internet.

I guess you are referring to lazarus.


Oh horror: The meta-package lazarus-0.9.30.4 forces 70MB of 
documentation down my throat!  That's not freedom of choice, that is 
outragous!  That package should only recommend its dependencies, for 
those 1-2% custom users needing the convenience of the meta-package 
without the burden og that documentation part.


As with any package available in Debian: Just don't install it if you do 
not like what the package does!

It really is that simple!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
"Eugene V. Lyubimkin"  writes:

> On 2012-07-11 14:33, Gergely Nagy wrote:
>> "Eugene V. Lyubimkin"  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:
 https://lists.debian.org/debian-devel/2012/07/msg00219.html

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

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
enough.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d341uzsa.fsf@algernon.balabit

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
Steve McIntyre  writes:

> Gergely wrote:
>>Henrique de Moraes Holschuh  writes:
>>
>>> IMO, metapackages should "depend" on the absolutely required stuff (and many
>>> times that will be the empty set), "recommend" the rest, and maybe even
>>> "suggest" fringe packages.  This achieves maximum usability for more
>>> usecases, and malfunctions only in the unsupported case of "no install
>>> recommends by default" -- you should skip recommends always in a
>>> case-by-case basis.
>>
>>That also achives maximum annoyance, because if I want the full
>>platform, I'll have to go recommends/suggest hunting. (No, I'm *not*
>>going to turn on install-recommends.)
>
> Right. So you're arguing that all the packages should be listed as
> Depends: to make *your* life easier, when you're doing something
> different from what's recommended. Thanks for showing how much weight
> we should attach to your argument.

It's a meta-package, that pulls in a platform. If I install it, I want
the full platform, always. That's about it. If I install mono-complete,
I want the whole bloody thing, always. If I install kde-full, I want the
full KDE desktop, with all bells and whistles. If I install gnome, I
want the whole thing with all strings attached. That's what I consider a
meta-package's job.

If I want parts of it, I will install parts of it. Metas are a
convenience for the most common case: installing all of it.

Lets consider another case! Suppose I have Install-Recommends turned on,
and install a theoretical meta package, that has half of its stuff in
recommends, because they're not strictly necessary, but merely enhance
the system. Lets suppose one of these enhancements include a tool I use
every once in a while, but not daily.

Now, a few months later, a transition comes about, and this package I
have gets removed, because another thing I update
breaks/conflicts/whatevers it. Since it's a recommends only, my package
manager will most likely want to remove it.

I now have two options: I either notice this, and stop the upgrade, or I
don't and poof, part of the platform's gone. I installed the full thing,
and lost part of it. I'm not happy.

As for why I wouldn't notice? Because I trust the system to do the right
thing, and I do automatic, unattended upgrades. Not an uncommon thing to
do, I believe.

But with recommends, the system failed me here, and removed part of the
platform that I *explicitly* installed.

And I had Install-Recommends turned on.

Thank you, I'd rather have Depends, and a reliable way to keep the full
platform on my system. Would I want to remove parts of it, I already
have the power to do that with the status quo. I can even keep up with
the meta package easily, if I choose to do so.

I don't know about you, but I prefer my systems reliable and I
absolutely hate when it wants to screw me over and try to remove parts
of stuff I explicitly asked it to install.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87629tuz4v.fsf@algernon.balabit

Re: Recommends for metapackages

2012-07-12 Thread Abou Al Montacir 
On Thu, 2012-07-12 at 11:09 +0200, Jonas Smedegaard wrote:

> On 12-07-12 at 10:28am, Abou Al Montacir wrote:
> > I'm maintaining a package which upstream delivers as all in one 
> > (600MB) and refuses to support splitting. I've split it into 22 
> > packages because I know and got requests from users who want to have 
> > it in machines with small disks and/or low internet.
> 
> I guess you are referring to lazarus.
> 
> 
> Oh horror: The meta-package lazarus-0.9.30.4 forces 70MB of 
> documentation down my throat!  That's not freedom of choice, that is 
> outragous!  That package should only recommend its dependencies, for 
> those 1-2% custom users needing the convenience of the meta-package 
> without the burden og that documentation part.
> 

Yes, but as you can see lazarus-ide-0.9.30.4 does not pull them. 

And even lazarus-0.9.30.4, which is intended for a typical Lazarus
installation (equiv gnome) is not forcing fpc, as you may want, to use
it with gpc or even gcc (I doubt it could, but you can try why forcing a
compiler?)


> As with any package available in Debian: Just don't install it if you do 
> not like what the package does!
> 
> It really is that simple!

I think that we really do not have the same understanding of
metapackage. You clearly want them strict and non flexible, I want them
convenient and flexible while ensuring desired functionality.

This does not end at gnome dependency but is really a general issue as
stated in other mails of this thread.

I really hate forcing things if not needed, just like the nature, have
minimal set of constraints, but ensure they got honored everywhere they
are relevant. Especially avoid dpakg --force-depends.

Cheers,

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
Andrei POPESCU  writes:

> On Mi, 11 iul 12, 14:41:50, Gergely Nagy wrote:
>> Andrei POPESCU  writes:
>> >
>> > Depending on how you do the package selection on your next installation 
>> > you might end up with rsyslog, but without logrotate[1].
>> 
>> I don't see how that would break anything. logrotate is not necessary
>> for log rotation, not with the syslog daemon of my choice at least. And
>> as you said yourself, log rotation isn't mandatory either.
>
> Given that I have turned off Recommends on that system because it's 
> space constrained (it's running from a 2GB USB stick) having logs not 
> rotated would have become a problem eventually.

a) logrotate is not required for log rotation.
b) You can still install it if you need it.

I can also stop installing my video driver, since it's not depended on
(nor recommended) by anything but the huge xserver-xorg-video-all
metapackage, and then call my system broken. *shrug*

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871ukhuyzx.fsf@algernon.balabit

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
Abou Al Montacir  writes:

>> As with any package available in Debian: Just don't install it if you do 
>> not like what the package does!
>> 
>> It really is that simple!
>
> I think that we really do not have the same understanding of
> metapackage. You clearly want them strict and non flexible, I want them
> convenient and flexible while ensuring desired functionality.

A flexible meta package is useless, however. If you want flexibility,
you can already install parts by themselves. If you want to remove them
with one broad swipe, that is also possible (create a meta that depends
on them all, so they get marked auto-installed, and install that meta;
or create a dummy package that conflicts with them, and install that -
both of these can be automated, and even beaten into a shape suitable
even for novice users, FYI).

However, if you want predictability, then Depends is your only
option. And if I install a meta package, I expect it to always install
the full thing, and keep those parts installed. Something that installs
almost the full thing, save a few, and allows distinctly-related stuff
to force removal of some of the meta is... well... unpredictable
rubbish, that is just asking for trouble.

Instead of fighting for Recommends, which would break your system in
various interesting ways later on[1], there's a third solution: noone
stops anyone from uploading a gnome-minimal package, which depends on
gnome-session and a few selected other parts, without n-m.

 [1]: http://article.gmane.org/gmane.linux.debian.devel.general/174877

And that goes for the rest of the meta packages: you can always
introduce more, customized for common needs.

So, we could say to users: You don't want the full gnome platform?
Neither do you want to pick parts of it by hand? Install gnome-minimal!

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txxdtj9b.fsf@algernon.balabit

Re: Recommends for metapackages

2012-07-12 Thread Thibaut Paumard 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 12/07/12 11:09, Jonas Smedegaard a écrit :
> As with any package available in Debian: Just don't install it if
> you do not like what the package does!

Hi,

There is a major difference between the gnome-core metapackages and
any other (meta) package in Debian: gnome-core is included is the
desktop task that approximately one user out of three installs (this
is my reading of popcon data). 4 installations _in popcon_.

Lets now assume that 1% of are unsatisfied by network-manager and
decide to remove it. That 400 users out of the popcon panel who need
to remove the gnome-core, and even task-gnome-desktop. All of the
sudden, 90% of their installed software disappears because they want
to get rid of this annoying little icon that believes it knows better
than them how to configure their bloody network.

Note that a meta-package such as task-gnome-desktop installs most of
its packages as _Recommends_, not _Depends_.

400 popcon installations is quite popular by popcon standards. It
corresponds to a package in the top 30% of all Debian packages with
more than 10 installs.

Kind regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/+nx4ACgkQ+37NkUuUiPH3TQCfdbb+YkVKvo7BD5IjBHRnnGe8
VKUAnikJty/OmeJlT2+Aink2pMHYF6Ib
=SevA
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffe9f1e.3010...@users.sourceforge.net

Re: Recommends for metapackages

2012-07-12 Thread Andreas Tille 
On Thu, Jul 12, 2012 at 11:06:40AM +0200, Gergely Nagy wrote:
> > Right. So you're arguing that all the packages should be listed as
> > Depends: to make *your* life easier, when you're doing something
> > different from what's recommended. Thanks for showing how much weight
> > we should attach to your argument.

:-)
Even if there seems to be no point in the discussion any more because
the arguing is void - I'll try some hint.
 
> It's a meta-package, that pulls in a platform. If I install it, I want
> the full platform, always. That's about it. If I install mono-complete,
> I want the whole bloody thing, always.

I think the attempt to ensure something always is not reasonable because
if the admin decided to break the system in whatever way chances are low
that you can do this.  You also can not do this "always" if I as a local
admin do some fancy stuff with preferences to get the dependency
resolution from somewhere else or do some fancy tricks with equivs.  So
your always argument is void for other ways to break my machine.

You have intentionally broken your system as it was defined in policy
and you now try one way to fix your personal broken system on all other
systems which are not broken in this specific way.

I have not read the whole thread but it seems to me that you have
ignored the system of recommends.

Kind regards

  Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120712095433.gc11...@an3as.eu

Re: Recommends for metapackages

2012-07-12 Thread Jonas Smedegaard 
On 12-07-12 at 11:26am, Abou Al Montacir wrote:
> On Thu, 2012-07-12 at 11:09 +0200, Jonas Smedegaard wrote:
> 
> > On 12-07-12 at 10:28am, Abou Al Montacir wrote:
> > > I'm maintaining a package which upstream delivers as all in one 
> > > (600MB) and refuses to support splitting. I've split it into 22 
> > > packages because I know and got requests from users who want to 
> > > have it in machines with small disks and/or low internet.
> > 
> > I guess you are referring to lazarus.
> > 
> > 
> > Oh horror: The meta-package lazarus-0.9.30.4 forces 70MB of 
> > documentation down my throat!  That's not freedom of choice, that is 
> > outragous!  That package should only recommend its dependencies, for 
> > those 1-2% custom users needing the convenience of the meta-package 
> > without the burden og that documentation part.
> > 
> 
> Yes, but as you can see lazarus-ide-0.9.30.4 does not pull them. 

...just as gnome-session doesn't depend on network-manager.


> And even lazarus-0.9.30.4, which is intended for a typical Lazarus 
> installation (equiv gnome) is not forcing fpc, as you may want, to use 
> it with gpc or even gcc (I doubt it could, but you can try why forcing 
> a compiler?)

...just as gnome-core isn't depending on, say, evolution.


> > As with any package available in Debian: Just don't install it if 
> > you do not like what the package does!
> > 
> > It really is that simple!
> 
> I think that we really do not have the same understanding of 
> metapackage. You clearly want them strict and non flexible, I want 
> them convenient and flexible while ensuring desired functionality.

Then why do the meta-package lazarus-0.9.30.4 depend on *anything*?

I guess it has to do with the "desired functionality" you as package 
maintainer want ensured by offering that meta-package.  An offering that 
anyone disagreeing with is free to not take, but instead explicitly 
install the custom subset they prefer.

> I really hate forcing things if not needed,

What is forced?  Do you force anyone to install lazarus-0.9.30.4?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Recommends for metapackages

2012-07-12 Thread Thibaut Paumard 
Hi,

Le 12/07/12 11:06, Gergely Nagy a écrit :
> Lets consider another case! Suppose I have Install-Recommends turned on,
> and install a theoretical meta package, that has half of its stuff in
> recommends, because they're not strictly necessary, but merely enhance
> the system. Lets suppose one of these enhancements include a tool I use
> every once in a while, but not daily.

A later upgrade to your beloved meta-package could very well drop this
dependency. If that's a tool that you know you want, I strongly suggest
you mark it as manually installed.

> As for why I wouldn't notice? Because I trust the system to do the right
> thing, and I do automatic, unattended upgrades. Not an uncommon thing to
> do, I believe.

You should always check what your package manager wants to remove. In my
experience, more often than not, aptitude tries to remove the full gnome
metapackage because of a temporarily unavailable depends.

Regards, thibaut.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffea089.4090...@free.fr

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
Andreas Tille  writes:

>> It's a meta-package, that pulls in a platform. If I install it, I want
>> the full platform, always. That's about it. If I install mono-complete,
>> I want the whole bloody thing, always.
>
> I think the attempt to ensure something always is not reasonable because
> if the admin decided to break the system in whatever way chances are low
> that you can do this.

And if the admin broke his system, I stop caring. Neither Recommends,
nor Depends will help there.

> You also can not do this "always" if I as a local
> admin do some fancy stuff with preferences to get the dependency
> resolution from somewhere else or do some fancy tricks with equivs.  So
> your always argument is void for other ways to break my machine.

Indeed so. But that, too, is outside of the scope. When I say "always",
I meant it as "on my system, wearing my root hat". What other people do
to their system, is none of my business.

> You have intentionally broken your system as it was defined in policy
> and you now try one way to fix your personal broken system on all other
> systems which are not broken in this specific way.

Erm, how have I broken my system? I did not. (Turning Install-Recommends
off is definitely not breaking my system, FYI.)

> I have not read the whole thread but it seems to me that you have
> ignored the system of recommends.

Alas, I did not, and I explained it elsewhere in this thread why and how
Recommends would break expectations, and why they are inferior to
Depends, as far as meta-packages are concerned.

I also presented ways to improve the current situation, none of which
involve Recommend, and neither would break any system, nor expectations,
and as such, are superior to Recommends - at least when talking about
meta packages.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipdtthm2.fsf@algernon.balabit

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
Thibaut Paumard  writes:

> Le 12/07/12 11:06, Gergely Nagy a écrit :
>> Lets consider another case! Suppose I have Install-Recommends turned on,
>> and install a theoretical meta package, that has half of its stuff in
>> recommends, because they're not strictly necessary, but merely enhance
>> the system. Lets suppose one of these enhancements include a tool I use
>> every once in a while, but not daily.
>
> A later upgrade to your beloved meta-package could very well drop this
> dependency.

While that may happen, that is far more unlikely than the case I
outlined, and a case I can live with.

> If that's a tool that you know you want, I strongly suggest
> you mark it as manually installed.

Problem is, at the time I installed the meta, I did not know about this
particular tool. It came with the platform, and I really do not want to
care which part of the platform it is.

It came with it, I expect it will stay as long as it is part of the
platform.

Recommends breaks that assumption.

>> As for why I wouldn't notice? Because I trust the system to do the right
>> thing, and I do automatic, unattended upgrades. Not an uncommon thing to
>> do, I believe.
>
> You should always check what your package manager wants to remove.

Why? In my setup, it will never remove things that are not marked
auto-install. I ensure that my system works, by having all dependencies
satisfied. (And any recommends or suggests I do need, I install by hand)

I do unattended upgrades for a reason: I don't want to spend time on
double-guessing something that should work automatically.

> In my experience, more often than not, aptitude tries to remove the
> full gnome metapackage because of a temporarily unavailable depends.

Well, mine won't do that, as I don't have gnome marked auto-install, so
it will abort the upgrade instead.

However, if things would move down to Recommends, it would happily
proceed to remove things I do use, just because I didn't install it by
hand...

And here we get back to the same issue others had: manual
bookkeeping. But this time, with recommends.

So pray tell me, how is Recommends any better, when I have to resort to
manual bookkeeping anyway?

-- 
|8]


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehohthas.fsf@algernon.balabit

Re: Recommends for metapackages

2012-07-12 Thread Jon Dowland 
On Wed, Jul 11, 2012 at 11:25:05PM +, Sune Vuorela wrote:
> for the 1-2% of people who has weird needs.

It's this proportion which I think is not consistent, nor agreed, amongst all 
developers.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120712125919.GD11211@debian

Re: Recommends for metapackages

2012-07-12 Thread Tomasz Rybak 
Dnia 2012-07-12, czw o godzinie 10:39 +0200, Gergely Nagy pisze:
> Noel David Torres Taño  writes:
> 
> >> Yet, we try to not diverge much from upstream, and maintain a good
> >> relationship with them. If they consider it core, so can we. Those who
> >> want to hand-pick parts of a meta package, can do so, we do not forbid.
> >
> > If we want to be user friendly, it is not a matter of "we do not forbid", 
> > it 
> > is a matter of "we make easy". Besides, low-level users will install 
> > Recommends by default, so they will get the whole box anyway. But medium or 
> > high level users may probably want N-M not to mess their network EVEN if 
> > they 
> > want the whole gnome desktop set.
> >> 
> >> I do not see the problem: those who want the full platform, can get it
> >> easily. Those who don't, and want to exclude some, they can do so easily
> >> too. A bit more work, but hey, if you're going to cherry pick, that will
> >> always involve more work.
> >> 
> >> 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 < - 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).

At first I thought it was a joke. But no, you really suggest that
everyone who wants to have up-to-date desktop environment
but without few packages (e.g. N-M or GDM) needs to create own package,
own local repository, and looks into it every time there is upgrade
to keep it current? And this is supposed to be simple?

I had phase of wanting to have under my control; heck, I even
was using Linux From Scratch, to which I was writing scripts to keep
it as up-to-date as possible. But later I become lazy and started to
think that there is better use for my time. After some time I found
Debian and liked idea of using other people's work and not having to
create my own distribution. After more time I started packaging
some software I am using so other people does not need to waste their
time building their own packages but may use my work and just do
# apt-get install python-pyopenl

Do you really think that forcing many people to maintain their
own repositories and metapackages is better  than just moving
e.g. N-M or GDM3 from Depends to Recommends?
Think about all those hours wasted, times however many people who
want to customise their desktops.

Regards.

-- 
Tomasz Rybak  GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak


signature.asc
Description: This is a digitally signed message part

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
Tomasz Rybak  writes:

> At first I thought it was a joke. But no, you really suggest that
> everyone who wants to have up-to-date desktop environment
> but without few packages (e.g. N-M or GDM) needs to create own package,
> own local repository, and looks into it every time there is upgrade
> to keep it current? And this is supposed to be simple?

Please read the rest of the mail, and the rest of the thread, where I
explain that Recommends gets you into the same manual bookeeping
situation anyway.

Unless, of course, you treat Recommends specially for meta
packages... and that is supposed to be simple how exactly?

> Do you really think that forcing many people to maintain their
> own repositories and metapackages is better  than just moving
> e.g. N-M or GDM3 from Depends to Recommends?

Forcing? No.

But it seems, I have to reiterate the solutions that are all superior to
downgrading stuff to Recommends:

0) Cherry pick packages by hand
===

Advantage is obviously that this is the most flexible way. Period.

Disadvantage: no easy way to remove everything in one go, and it's a bit
of a burden to follow the platform.

However, lets consider the average user using stable: how often does the
platform change? Zero times during a stable release. Zero. You might
have to follow changes during a dist-upgrade, but that, I believe, is
acceptable.

If you're not using stable, well, tough luck, but you made that choice
consciously, and should've been aware of the downsides, which may
include a bit of extra work on your part.

Still, even in that case, how often does or did the list of Dependencies
of the gnome meta-package change since squeeze? I don't expect it'd
changed much, save for the gnome2->gnome3 transition, and most of the
changes most probably wouldn't need followups anyway. If I'm mistaken,
please do correct me, however.

1) Use a custom meta package


The advantage here is that it's easy to do, easy to automate, and you
can easily follow the upstream meta-package, excluding only a few of its
dependencies.

The downside is obviously that you (or a script) has to maintain a local
repo. Personally, I couldn't care less what the tool that automates this
for me accomplishes that, as long as it can be fully automated (it can
be), but some may disagree.

And it's certainly not the most elegant solution.

2) Use dummy equivs packages


Instead of replacing the meta, you'd replace the dependencies you don't
want installed.

The advantage is that you don't have to maintain a local repo, and you
get to use the upstream meta as-is.

The downside is that you'll have a bunch of local dummy packages, and
you have to make them. Again, that can be scripted, and completely
hidden from the user.

Nevertheless, this is still not the most elegant solution.

3) Upload a gnome-minimal package or somesuch
=

The advantage is that it will have whatever you want. The downside is
that the maintainer must keep it up to date, and whoever disagrees what
constutites minimal, whill continue shouting.

Yet, this is straighforward, and places the burden on one person instead
of everyone who might want such a package.

X) Downgrade stuff to recommends


I do not consider this a solution, for reasons explained elsewhere,
where my main concern is that it breaks the assumption that installing a
platform (in this case, gnome) will install the whole thing, and it will
be available for my use at any time.

With recommends, there's a fair chance that a distinctly related package
forces part of the platform off, and the package manager will happily
remove them. Once the breakage is fixed, it will not reinstall them.

This can be worked around by removing the auto-installed flag from those
parts of the platform that I want to keep at all times, but then what is
the use of Recommends, when I have to cherry pick anyway? I could just
skip installing the meta, the net effect is the same (except, that
without the meta, there are no expectations to break).

> Think about all those hours wasted, times however many people who
> want to customise their desktops.

I still don't see the problem with installing a subset by hand. Advanced
users can script it, novices will only need to hand pick once. Done. 10
minutes job.

Compare that to the hours wasted trying to figure out what forced part
of the platform off my system and when, during an unattended
upgrade.. Yes, I do those, because I want to trust the system doing the
right thing, and keeping stuff I installed intact and complete.

If I have to double-guess the package manager, then there is something
seriously wrong. Recommends would force me to do that.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq

Re: Recommends for metapackages

2012-07-12 Thread Tomasz Rybak 
Dnia 2012-07-12, czw o godzinie 15:46 +0200, Gergely Nagy pisze:
> Tomasz Rybak  writes:
> 
> > At first I thought it was a joke. But no, you really suggest that
> > everyone who wants to have up-to-date desktop environment
> > but without few packages (e.g. N-M or GDM) needs to create own package,
> > own local repository, and looks into it every time there is upgrade
> > to keep it current? And this is supposed to be simple?
> 
> Please read the rest of the mail, and the rest of the thread, where I
> explain that Recommends gets you into the same manual bookeeping
> situation anyway.

I might be misunderstanding situation with dependencies here then.

Let's assume that I have set my system to install recommended
packages by default and I try install "gnome" package.
It has some packages in Depends, some in Recommends.
If it has N-M in Recommends, I can unselect it during installation.
This will result with my system having gnome with all its dependencies
and recommendation installed except for N-M.
Then some time later during upgrade it'll upgrade all packages
but will not install N-M; at the same time it'll install
new package that was added to Recommends in that new version.
It this correct description of apt behaviour, or have
I misunderstood something?

Regards.
-- 
Tomasz Rybak  GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak


signature.asc
Description: This is a digitally signed message part

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
FTR: Please don't CC me on list mail. I'm tired of setting M-F-T.

Tomasz Rybak  writes:

> Dnia 2012-07-12, czw o godzinie 15:46 +0200, Gergely Nagy pisze:
>> Tomasz Rybak  writes:
>> 
>> > At first I thought it was a joke. But no, you really suggest that
>> > everyone who wants to have up-to-date desktop environment
>> > but without few packages (e.g. N-M or GDM) needs to create own package,
>> > own local repository, and looks into it every time there is upgrade
>> > to keep it current? And this is supposed to be simple?
>> 
>> Please read the rest of the mail, and the rest of the thread, where I
>> explain that Recommends gets you into the same manual bookeeping
>> situation anyway.
>
> I might be misunderstanding situation with dependencies here then.
>
> Let's assume that I have set my system to install recommended
> packages by default and I try install "gnome" package.
> It has some packages in Depends, some in Recommends.
> If it has N-M in Recommends, I can unselect it during installation.

Yes. And you can remove it later too.

> This will result with my system having gnome with all its dependencies
> and recommendation installed except for N-M.

Yes.

> Then some time later during upgrade it'll upgrade all packages
> but will not install N-M; at the same time it'll install
> new package that was added to Recommends in that new version.

As far as I remember, it will not install new recommends.

> It this correct description of apt behaviour, or have
> I misunderstood something?

More or less, except that to the best of my knowledge, it will not
install new recommends on upgrade. And that makes sense, and is good so,
otherwise it will attempt to install all recommends I explicitly did not
install on each upgrade - no thanks. (Or we need to introduce yet
another complexity into the system, to mark packages as
not-to-install-ever. I doubt we have that now... but perhaps hold on an
uninstalled package works that way? I don't know.)

But, the problem I'm talking about is not related to this. The problem I
see is when I have a gnome meta-package, that recommends, say,
totem. Now, lets suppose I'm also running unstable, for one reason or
the other, and a transition comes along, and something has a breaks on
stuff totem depends on, and the package manager decides to remove totem.

Weeks later, when I want to watch a movie, at the end of the world, with
no network connectivify, I realize that something pulled my movie player
out of me.

I would be very, very sad.

Of course, silly me, why do I run unstable? And why don't I pay
attention to what my upgrades do? Well, I run unstable because I work
with it, and it has up-to-date stuff I have to work with. And running
unstable is far easier than running testing and cherry-picking (did I
mention I hate manual bookkeeping?). I do unattended upgrades, because I
trust the system to keep everything I installed, installed. I installed
the gnome meta-package because I want the full thing, bells, whistles
and crap included.

I could, of course, mark totem manually installed, but then I'm back to
manual bookkeeping, could've installed the whole stuff by cherry-picking
each component, and that makes the meta-package useless for me, and
destroys the argument that recommends would result in less bookkeeping.

Thus, here's an example where Recommends *will break* an existing
system.

Oh, and since apt won't install new recommends on upgrade, to the best
of my knowledge, I won't get totem back once the
transition/breakage/whatever is fixed, either. While if it would be a
dependency, the upgrade would abort, because it'd try to remove a
package marked as manually installed.

But similarly, if I ran stable, and one of the meta packages I installed
had a recommends on a piece of software, and I try to install something
that conflicts with it (either directly, or indirectly, via another meta
package, for example), then this piece of software gets removed. I may
or may not notice that - I might not even know wtf totem is, a novice
user who first sees Linux certainly won't - so it gets removed.

It won't come back, unless I install it.

As far as I'm concerned, this defeats the purpose of the meta-package,
because it breaks my expectation that whatever else it pulls in, will
stay there as long as the meta is installed.

Perhaps that is a silly assumption, but if it is, then there's no point
in having anything in a meta's depends at all, as it's pretty much a
supermarket you can cherry pick from. In that case, I would be very
disappointed.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hatd6l1n.fsf@algernon.balabit

Re: Recommends for metapackages

2012-07-12 Thread Svante Signell 
On Thu, 2012-07-12 at 05:42 +0200, Adam Borowski wrote:
> On Wed, Jul 11, 2012 at 09:32:19PM -0600, Philipp Kern wrote:
> > On Wed, Jul 11, 2012 at 07:21:00PM +0100, Noel David Torres Taño wrote:
> > > Installing N-M breaks unrelated software.
> > 
> > No. At most it breaks *related* software.
> 
> Exactly, that's why it's the "gnome-core" package that's RC-buggy, not
> network-manager.  Unless someone thinks a desktop environment's core
> function is to mess with the network, that is.

Couldn't say it better myself. Why does the desktop core mess with the
network settings??



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1342125195.4582.8.camel@x60

RFC: Why are so many debian packages outdated?

2012-07-12 Thread Svante Signell 
Hello,

Now when Wheezy is about to be released I would like to raise an issue.
How come that there are still so many outdated packages becoming part
of Wheezy. Some package maintainers are very responsive in upgrading to
new upstream releases, others are having packages several years old.

Something is not OK, compared to other distributions, why releasing
outdated upstream software (I'm not thinking about essential packages
here). Yes, I know about the rock solid stability, that's appreciated!.
But it should also reflect current software. gcc-4.7 is a good example
of current software (it will part of squeeze even if there were a lot
of complaints recently...)

The Debian package maintainer system is maybe too old-fashioned? Or more
NMUs should be made/allowed/encouraged? I know all packaging is made by
volunteers at their spare time, but anyway. Debian is one of the best
distributions, what about raising the bar a little higher?








-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1342127161.4582.26.camel@x60

Re: RFC: Why are so many debian packages outdated?

2012-07-12 Thread Timo Juhani Lindfors 
Svante Signell  writes:
> NMUs should be made/allowed/encouraged? I know all packaging is made by
> volunteers at their spare time, but anyway. Debian is one of the best
> distributions, what about raising the bar a little higher?

The only way you can really improve the situation is to help with the
packages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/84fw8w4qy0@sauna.l.org

Re: RFC: Why are so many debian packages outdated?

2012-07-12 Thread Svante Signell 
On Fri, 2012-07-13 at 00:20 +0300, Timo Juhani Lindfors wrote:
> Svante Signell  writes:
> > NMUs should be made/allowed/encouraged? I know all packaging is made by
> > volunteers at their spare time, but anyway. Debian is one of the best
> > distributions, what about raising the bar a little higher?
> 
> The only way you can really improve the situation is to help with the
> packages.

I already have (with patches to bug reports), but becoming a Debian
maintainer I have not yet applied for. Maybe doing some packaging, and
ask for a sponsor will be a good way to get involved more, as a start. 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1342128347.4582.31.camel@x60

Re: RFC: Why are so many debian packages outdated?

2012-07-12 Thread Paul Wise 
On Thu, Jul 12, 2012 at 3:06 PM, Svante Signell wrote:

> Now when Wheezy is about to be released I would like to raise an issue.
> How come that there are still so many outdated packages becoming part
> of Wheezy. Some package maintainers are very responsive in upgrading to
> new upstream releases, others are having packages several years old.

Yet another thread about this decade old "issue" is not really going
to help the release, since it takes time for reading it away from
potential RC bug fixing time.

Folks who are interested in avoiding reading threads like this might
be interested in the tool being discussed in this event at DebConf12:

http://penta.debconf.org/dc12_schedule/events/951.en.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6HfOoeaju1vA7oW4e00A9-PKCSQLzKyD1ORm=t+csh...@mail.gmail.com

Re: Recommends for metapackages

2012-07-12 Thread Andrei POPESCU 
On Jo, 12 iul 12, 15:46:05, Gergely Nagy wrote:
> 
> X) Downgrade stuff to recommends
> 
> 
> I do not consider this a solution, for reasons explained elsewhere,
> where my main concern is that it breaks the assumption that installing a
> platform (in this case, gnome) will install the whole thing, and it will
> be available for my use at any time.

Well, it will, in all but unusual installations :)
 
> With recommends, there's a fair chance that a distinctly related package
> forces part of the platform off, and the package manager will happily
> remove them. Once the breakage is fixed, it will not reinstall them.

Could you please elaborate on that? The only thing I can think of that 
would force some packages to not be installed (or removed) is a 
Conflicts (or unsatisfiable Depends, but this shouldn't happen in 
stable).

With Recommends you get a simple prompt that a specific package will be 
uninstalled and comparing the descriptions will probably give a hint to 
any user that those packages might conflict (assuming they don't look at 
the Conflicts).

With Depends aptitude will suddenly want to remove a whole bunch of 
packages (that may or may not look related) and apt-get will suggest you 
to do this via autoremove. Then you have go hunting with apt-mark, yay!

> This can be worked around by removing the auto-installed flag from those
> parts of the platform that I want to keep at all times, but then what is
> the use of Recommends, when I have to cherry pick anyway? I could just
> skip installing the meta, the net effect is the same (except, that
> without the meta, there are no expectations to break).

Are you talking about testing or sid?
 
> I still don't see the problem with installing a subset by hand. Advanced
> users can script it, novices will only need to hand pick once. Done. 10
> minutes job.

IMO the main problem is:

# aptitude remove package
Following packages will be removed:
[Big list with 100+ packages]
 
> Compare that to the hours wasted trying to figure out what forced part
> of the platform off my system and when, during an unattended
> upgrade.. Yes, I do those, because I want to trust the system doing the
> right thing, and keeping stuff I installed intact and complete.

Sorry, I thought we were talking about stable, why would something like 
that happen.
 
Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: RFC: Why are so many debian packages outdated?

2012-07-12 Thread Svante Signell 
Adding debian-devel to the recipients. I think the question belongs
there.

On Thu, 2012-07-12 at 21:39 +, Bart Martens wrote:
> On Thu, Jul 12, 2012 at 11:25:47PM +0200, Svante Signell wrote:
> > On Fri, 2012-07-13 at 00:20 +0300, Timo Juhani Lindfors wrote:
> > > Svante Signell  writes:
> > > > NMUs should be made/allowed/encouraged? I know all packaging is made by
> > > > volunteers at their spare time, but anyway. Debian is one of the best
> > > > distributions, what about raising the bar a little higher?
> > > 
> > > The only way you can really improve the situation is to help with the
> > > packages.
> > 
> > I already have (with patches to bug reports), but becoming a Debian
> > maintainer I have not yet applied for. Maybe doing some packaging, and
> > ask for a sponsor will be a good way to get involved more, as a start. 
> 
> Yes, doing some packaging via a sponsor is a way to immediately start
> contributing to Debian.

What to do if the maintainer is unresponsive? Ask somebody else to do
the upload, or pinging the maintainer again? Alternatives (what about
wine 1.2++)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1342129673.4582.41.camel@x60

Re: Recommends for metapackages

2012-07-12 Thread Andrei POPESCU 
On Jo, 12 iul 12, 17:44:52, Gergely Nagy wrote:
> 
> > Then some time later during upgrade it'll upgrade all packages
> > but will not install N-M; at the same time it'll install
> > new package that was added to Recommends in that new version.
> 
> As far as I remember, it will not install new recommends.
 
http://lists.debian.org/caaz6_fdtaydt1ubp08yf0d8l0jusffy1rzyhvmvztfcjeoc...@mail.gmail.com

> > It this correct description of apt behaviour, or have
> > I misunderstood something?
> 
> More or less, except that to the best of my knowledge, it will not
> install new recommends on upgrade. And that makes sense, and is good so,
> otherwise it will attempt to install all recommends I explicitly did not
> install on each upgrade - no thanks. (Or we need to introduce yet
> another complexity into the system, to mark packages as
> not-to-install-ever. I doubt we have that now... but perhaps hold on an
> uninstalled package works that way? I don't know.)

Pin it to -1 ;)

> But, the problem I'm talking about is not related to this. The problem I
> see is when I have a gnome meta-package, that recommends, say,
> totem. Now, lets suppose I'm also running unstable, for one reason or
> the other, and a transition comes along, and something has a breaks on
> stuff totem depends on, and the package manager decides to remove totem.
> 
> Weeks later, when I want to watch a movie, at the end of the world, with
> no network connectivify, I realize that something pulled my movie player
> out of me.
> 
> I would be very, very sad.
> 
> Of course, silly me, why do I run unstable? And why don't I pay
> attention to what my upgrades do? Well, I run unstable because I work
> with it, and it has up-to-date stuff I have to work with. And running
> unstable is far easier than running testing and cherry-picking (did I
> mention I hate manual bookkeeping?). I do unattended upgrades, because I
> trust the system to keep everything I installed, installed. I installed
> the gnome meta-package because I want the full thing, bells, whistles
> and crap included.

Sorry, but IMNSHO running sid with unattended upgrades just asks for 
trouble. But then again IANADD, if Debian wants to optimize for this use 
case who am I to disagree? :)
 
> I could, of course, mark totem manually installed, but then I'm back to
> manual bookkeeping, could've installed the whole stuff by cherry-picking
> each component, and that makes the meta-package useless for me, and
> destroys the argument that recommends would result in less bookkeeping.
> 
> Thus, here's an example where Recommends *will break* an existing
> system.
> 
> Oh, and since apt won't install new recommends on upgrade, to the best
> of my knowledge, I won't get totem back once the
> transition/breakage/whatever is fixed, either. While if it would be a
> dependency, the upgrade would abort, because it'd try to remove a
> package marked as manually installed.
> 
> But similarly, if I ran stable, and one of the meta packages I installed
> had a recommends on a piece of software, and I try to install something
> that conflicts with it (either directly, or indirectly, via another meta
> package, for example), then this piece of software gets removed. I may
> or may not notice that - I might not even know wtf totem is, a novice
> user who first sees Linux certainly won't - so it gets removed.

Well, if the purpose of the Depends are to protect a novice from 
removing packages by mistake that surely a package manager offering to 
remove 100+ packages should definitely sound an alarm.

But with apt-get you will get only two packages uninstalled (the package 
with the conflict and the metapackage depending on it). The big surprise 
will come only later, when apt-get suddenly suggest you should run 
'autoremove' to get rid of some 100+ packages that look like not needed 
anymore.
 
> It won't come back, unless I install it.
> 
> As far as I'm concerned, this defeats the purpose of the meta-package,
> because it breaks my expectation that whatever else it pulls in, will
> stay there as long as the meta is installed.

Did you consider creating your own meta-package? It shouldn't take you 
more than 5 minutes to write an apt hook to get the control file and 
s/Recommends/Depends/

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Recommends for metapackages

2012-07-12 Thread Andrei POPESCU 
On Jo, 12 iul 12, 12:10:29, Gergely Nagy wrote:
> 
> Erm, how have I broken my system? I did not. (Turning Install-Recommends
> off is definitely not breaking my system, FYI.)

It means you are running with a non-default configuration and you should 
be aware of the side-effects.

The attitude that Recommends are not important is probably the reason 
why:

1. some Maintainers use Depends, where Recommends would be more 
appropriate

2. some Maintainers use Recommends, where Suggests would be more 
appropriate

Dear Maintainers,

Please don't forget that a Recommends will pull in packages in all but 
unusual installations :)
Therefor you may be bloating your user's computer needlessly and make it 
really hard for them to clean up afterwards (in case of circular 
Recommends packages will be kept installed even if marked as 
auto-installed).

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Bug#681404: ITP: garmin-plugin -- browser plugin for communication with the Garmin Connect service

2012-07-12 Thread Ralf Treinen 
Package: wnpp
Severity: wishlist
Owner: Ralf Treinen 

* Package name: garmin-plugin
  Version : 0.3.12-1
  Upstream Author : Andreas Diesner 
* URL : http://www.andreas-diesner.de/garminplugin/
* License : GPL-3
  Programming Lang: C++
  Description : browser plugin for communication with the Garmin Connect 
service

 This browser plugin has the same methods and properties as the official 
 Garmin Communicator Plugin (http://www8.garmin.com/products/communicator/).
 It can be used to transfer GPX files (Geocache Descriptions) to your garmin
 device using the official Garmin Javascript API. Its functionality depends on
 the device you use. 
  - Edge305/Forerunner305: ReadFitnessData, ReadGpsData, No write support
  - Edge705/Oregon/Dakota: ReadFitnessData, ReadGpsData, Write Gpx files
  - Edge800: ReadFitnessData, Write Gpx/Tcx Files
  - Other devices: Executes external command to write Gpx to device 

Remarks:
- will be team maintained by the the pkg-running team
- possibly has to go into contrib since it is made for interaction with a
  non-free service.

-Ralf.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120712223751.14108.92490.report...@hydrogene.pps.jussieu.fr

Work-needing packages report for Jul 13, 2012

2012-07-12 Thread wnpp 
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 461 (new: 7)
Total number of packages offered up for adoption: 146 (new: 0)
Total number of packages requested help for: 64 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   ginspector (#681284), orphaned today
 Installations reported by Popcon: 52

   ladr (#681042), orphaned 2 days ago
 Description: the LADR deduction library, development files
 Installations reported by Popcon: 59

   libcorona-perl (#680774), orphaned 4 days ago
 Description: Coro based PSGI web server server using Coro
 Installations reported by Popcon: 1

   otter (#681043), orphaned 2 days ago
 Description: resolution-style theorem prover
 Installations reported by Popcon: 32

   prover9-manual (#681044), orphaned 2 days ago
 Description: documentation for Prover9 and associated programs
 Installations reported by Popcon: 24

   python-unac (#680459), orphaned 6 days ago
 Description: Library to remove accents from string or character
 Installations reported by Popcon: 24

   tcpser (#681045), orphaned 2 days ago
 Description: emulate a Hayes compatible modem
 Installations reported by Popcon: 16

454 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 146 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 892 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 55290

   asymptote (#517342), requested 1231 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 3194

   athcool (#278442), requested 2816 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 84

   balsa (#642906), requested 291 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 258

   bastille (#592137), requested 705 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 217

   boinc (#511243), requested 1281 days ago
 Description: BOINC distributed computing
 Installations reported by Popcon: 1672

   cardstories (#624100), requested 444 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 4

   chromium-browser (#583826), requested 774 days ago
 Description: Chromium browser
 Installations reported by Popcon: 10295

   debtags (#567954), requested 892 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2496

   doc-central (#566364), requested 901 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 201

   elvis (#432298), requested 1830 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Installations reported by Popcon: 299

   fbcat (#565156), requested 911 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 151

   flightgear (#487388), requested 1482 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 829

   freeipmi (#628062), requested 413 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 1702

   gnat-4.4 (#539633), requested 1549 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 Installations reported by Popcon: 1646

   gnat-gps (#496905), requested 1414 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 421

   gnokii (#677750), requested 26 days ago
 Description: Datasuite for mobile phone management
 Installations reported by Popcon: 2495

   gnupg (#660685), requested 143 days ago
 Description: GNU privacy guard - a free PGP replacement
 Installations reported by Popcon: 122504

   golang (#668870), requested 88 days ago
 Description: Go programming language compiler - metapackage
 Installations reported by Popcon: 243

   gpa (#663405), requested 124 days ago
 Description: GNU Privacy Assistant (GPA)
 Installations reported by Popcon: 507

   grub2 (#248397), requested 2985 days ago
 Description: GRand Unifie

Bug#681418: debugfs is a big security hole

2012-07-12 Thread Ben Hutchings 
Package: src:linux
Version: 3.2.21-3
Severity: important
Tags: security

As discussed here
.

I certainly consider mounting of debugfs to be significant security
liability.  I'm not at all happy that people use it as the basis for
end-user applications that quietly mount debugfs if they find it isn't
yet mounted.  Even if their corner of debugfs is robust, all the other
stuff exposed by random drivers may not be.

Debian has at least one such application package (blktrace) which
mounts debugfs from its init script.

I would like to address this by backporting this feature:

commit d6e486868cde585842d55ba3b6ec57af090fc343
Author: Ludwig Nussel 
Date:   Wed Jan 25 11:52:28 2012 +0100

debugfs: add mode, uid and gid options

and then changing the default mode (mask) to be 0700.  This should
leave debugfs functional (most such applications will require root
anyway) and allow users to relax permissions if they really don't
care about the security problems.

However, currently there is not a single place for the user options.
I think that either (1) debugfs should be mounted by default in a
similar way to other pseudo-filesystems, or (2) debugfs should have a
noauto entry in /etc/fstab where users can set options, and packages
may use 'mount /sys/kernel/debug' to mount debugfs with those options
(not 'mount -t debugfs debugfs /sys/kernel/debug', as now).

Ben.

-- System Information:
Debian Release: wheezy/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120713033708.3307.93550.report...@deadeye.wl.decadent.org.uk

Re: Recommends for metapackages

2012-07-12 Thread Wouter Verhelst 
On Tue, Jul 10, 2012 at 04:18:17PM +0200, Gergely Nagy wrote:
> "Eugene V. Lyubimkin"  writes:
> 
> > On 2012-07-10 15:32, Josselin Mouette wrote:
> >> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : 
> >> > What's wrong with Recommends: in that case?  It seems to perfectly
> >> > match the "makes life easier for  >> > XXX>" scenario you describe.
> >> 
> >> Recommends is wrong for metapackages because it gets upgrades very
> >> wrong. This is why it is used very marginally.
> >
> > Standards should not depend on implementation details. I see zero
> > reasons why metapackages are (or should be) specific here. Whatever $it
> > that gets upgrades wrong should be fixed instead.
> 
> 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.

Of course it does. Five years ago, when apt didn't install recommends by
default, recommends might not have been appropriate, but these days it
is.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120713040331.gl2...@grep.be

Re: Bug#681404: ITP: garmin-plugin -- browser plugin for communication with the Garmin Connect service

2012-07-12 Thread Tollef Fog Heen 
]] Ralf Treinen 

>  This browser plugin has the same methods and properties as the official 
>  Garmin Communicator Plugin (http://www8.garmin.com/products/communicator/).
>  It can be used to transfer GPX files (Geocache Descriptions) to your garmin
>  device using the official Garmin Javascript API. Its functionality depends on
>  the device you use. 

Yay!

> - possibly has to go into contrib since it is made for interaction with a
>   non-free service.

There's nothing stopping it from being used with free running sites, so
I don't see why.

(I've pondered integrating support in Turan for instance, which is free.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874npcjkx4@xoog.err.no

Re: Recommends for metapackages

2012-07-12 Thread Tollef Fog Heen 
]] Gergely Nagy 

> Instead of fighting for Recommends, which would break your system in
> various interesting ways later on[1], there's a third solution: noone
> stops anyone from uploading a gnome-minimal package, which depends on
> gnome-session and a few selected other parts, without n-m.

I would think it quite rude to trample on the gnome-* namespace unless
this is well coordinated with the GNOME packagers.  If they're happy
with it, that's a different situation.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk74i628@xoog.err.no

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
Wouter Verhelst  writes:

> On Tue, Jul 10, 2012 at 04:18:17PM +0200, Gergely Nagy wrote:
>> "Eugene V. Lyubimkin"  writes:
>> 
>> > On 2012-07-10 15:32, Josselin Mouette wrote:
>> >> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : 
>> >> > What's wrong with Recommends: in that case?  It seems to perfectly
>> >> > match the "makes life easier for > >> > XXX>" scenario you describe.
>> >> 
>> >> Recommends is wrong for metapackages because it gets upgrades very
>> >> wrong. This is why it is used very marginally.
>> >
>> > Standards should not depend on implementation details. I see zero
>> > reasons why metapackages are (or should be) specific here. Whatever $it
>> > that gets upgrades wrong should be fixed instead.
>> 
>> 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.
>
> Of course it does. Five years ago, when apt didn't install recommends by
> default, recommends might not have been appropriate, but these days it
> is.

Does it pull in recommends on upgrade? No? Just how useful are they
then, for following the changes in the meta?

Does Recommends guarantee that the platform will stay intact, unless I
explicitly remove a recommended package? No? That'll be fun! "I
installed gnome, but an upgrade wants to remove totem! What's up with
that??" Is no better than "I installed gnome, but an upgrade wants to
remove it altogether", except the former is more dangerous, as it wants
to remove a package you didn't install by hand, and may not know what it
does. For novice users, the former is far more dangerous, because they
may not know what the removed package is for. At least with Depends, the
same upgrade would want to remove the Gnome metapackage, and they'd know
what THAT is, and can stop the upgrade.

No, recommends are a terrible idea for meta-packages.

-- 
|8], who still doesn't like being CC'd on list mail.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9z4tcbd@luthien.mhp

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
Tollef Fog Heen  writes:

> ]] Gergely Nagy 
>
>> Instead of fighting for Recommends, which would break your system in
>> various interesting ways later on[1], there's a third solution: noone
>> stops anyone from uploading a gnome-minimal package, which depends on
>> gnome-session and a few selected other parts, without n-m.
>
> I would think it quite rude to trample on the gnome-* namespace unless
> this is well coordinated with the GNOME packagers.  If they're happy
> with it, that's a different situation.

I agree. But from what I've seen so far, it seems to me that it would be
far easier to persuade the relevant people to accept a new meta, than to
downgrade anything to Recommends.

(Also a much better idea than Recommends :)

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87629stc7k@luthien.mhp

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
Andrei POPESCU  writes:

> On Jo, 12 iul 12, 15:46:05, Gergely Nagy wrote:
>> 
>> X) Downgrade stuff to recommends
>> 
>> 
>> I do not consider this a solution, for reasons explained elsewhere,
>> where my main concern is that it breaks the assumption that installing a
>> platform (in this case, gnome) will install the whole thing, and it will
>> be available for my use at any time.
>
> Well, it will, in all but unusual installations :)

No. See below.

>> With recommends, there's a fair chance that a distinctly related package
>> forces part of the platform off, and the package manager will happily
>> remove them. Once the breakage is fixed, it will not reinstall them.
>
> Could you please elaborate on that? The only thing I can think of that 
> would force some packages to not be installed (or removed) is a 
> Conflicts (or unsatisfiable Depends, but this shouldn't happen in 
> stable).

As far as stable is concerned, a conflict, yes. For unstable, where
package releations are more interesting, unsatisfiable Depends too.

> With Recommends you get a simple prompt that a specific package will be 
> uninstalled and comparing the descriptions will probably give a hint to 
> any user that those packages might conflict (assuming they don't look at 
> the Conflicts).

So, on each upgrade, the user would need to:

- Double guess the system, to not botch an upgrade
- Read N number of package descriptions to figure out wtf that thing it
  wants to remove is.

How is that user friendly and good?

> With Depends aptitude will suddenly want to remove a whole bunch of 
> packages (that may or may not look related) and apt-get will suggest you 
> to do this via autoremove. Then you have go hunting with apt-mark,
> yay!

With Depends, I will instantly know something is botched. With
recommends, it will happily remove half the platform unless I stop it
manually. Which I most likely wont, as I'm doing unattended
upgrades. And I do unattended upgrades, because I trust the system to do
the right thing, and not remove stuff from under me that it should not.

I *hate* doing things manually, that's why I'm using a bloody high-level
package manager. If it forces me to double-guess it, check a lot of
things during upgrades, I might aswell go back to downloading packages
by hand and using dpkg directly myself.

>> This can be worked around by removing the auto-installed flag from those
>> parts of the platform that I want to keep at all times, but then what is
>> the use of Recommends, when I have to cherry pick anyway? I could just
>> skip installing the meta, the net effect is the same (except, that
>> without the meta, there are no expectations to break).
>
> Are you talking about testing or sid?

Either.

>> I still don't see the problem with installing a subset by hand. Advanced
>> users can script it, novices will only need to hand pick once. Done. 10
>> minutes job.
>
> IMO the main problem is:
>
> # aptitude remove package
> Following packages will be removed:
> [Big list with 100+ packages]

How is that better than:

# aptitude upgrade
Following packages will be removed:
[A list of 10+ packages you have no clue about]

A novice user will answer no to the former, and keep his system
intact. He will answer yes to the latter, because he never heard of
those packages before, and trusts the package manager to do the right
thing.

Hi, you have a broken system.

But, it can also happen when you remove a dependency of a recommended
package:

# aptitude remove dependency-of-a-recommended-package
[ List of 10+ packages you have no clue about ]

There goes your video player, your audio player and probably a bunch of
other things.

Unless the user double-checks what those 10+ packages are, which most
likely he won't.

>> Compare that to the hours wasted trying to figure out what forced part
>> of the platform off my system and when, during an unattended
>> upgrade.. Yes, I do those, because I want to trust the system doing the
>> right thing, and keeping stuff I installed intact and complete.
>
> Sorry, I thought we were talking about stable, why would something like 
> that happen.

If we're talking about stable only, there's even less reason for
Recommends.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5morx0a@luthien.mhp

Re: Recommends for metapackages

2012-07-12 Thread Gergely Nagy 
Andrei POPESCU  writes:

> On Jo, 12 iul 12, 12:10:29, Gergely Nagy wrote:
>> 
>> Erm, how have I broken my system? I did not. (Turning Install-Recommends
>> off is definitely not breaking my system, FYI.)
>
> It means you are running with a non-default configuration and you should 
> be aware of the side-effects.

I am aware of side-effects, thank you. I turn it off because of the
side-effects. That does not make my system broken, however.

> Please don't forget that a Recommends will pull in packages in all but 
> unusual installations :)

But also keep in mind, that once a package is installed, adding new
recommends will not pull those new things in on an upgrade.

I do not think upgrade is an unusual situation, fwiw. For stable, it is,
for everything else, not so much. But half the arguments for Recommends
(with regards to meta-packages) are invalid for stable anyway.

The only valid argument for stable is that apt-get remove gnome will
want to remove a whole bunch of stuff. My counter argument is that doing
so is safer than screwing up the user's system.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txxcrwu3@luthien.mhp