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.
<sarcasm>
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.
</sarcasm>
As with any package available in Debian: Just don't install it if you do
not like what the package does!
[x] quote me freely [ ] ask before reusing [ ] keep private
07-12-2012, 09:09 AM
Gergely Nagy
Recommends for metapackages
Andrei POPESCU <andreimpopescu@gmail.com> writes:
> On Mi, 11 iul 12, 14:41:50, Gergely Nagy wrote:
>> Andrei POPESCU <andreimpopescu@gmail.com> 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/871ukhuyzx.fsf@algernon.balabit
07-12-2012, 09:26 AM
Abou Al Montacir
Recommends for metapackages
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.
<sarcasm>
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.
</sarcasm>
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,
07-12-2012, 09:34 AM
Gergely Nagy
Recommends for metapackages
Abou Al Montacir <abou.almontacir@sfr.fr> 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.
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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87txxdtj9b.fsf@algernon.balabit
07-12-2012, 09:54 AM
Andreas Tille
Recommends for metapackages
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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120712095433.GC11965@an3as.eu">http://lists.debian.org/20120712095433.GC11965@an3as.eu
07-12-2012, 09:55 AM
Thibaut Paumard
Recommends for metapackages
-----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). 40000 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/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FFE9F1E.3010108@users.sourceforge.net">http://lists.debian.org/4FFE9F1E.3010108@users.sourceforge.net
07-12-2012, 10:00 AM
Jonas Smedegaard
Recommends for metapackages
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.
> >
> > <sarcasm>
> > 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.
> > </sarcasm>
>
> 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?
[x] quote me freely [ ] ask before reusing [ ] keep private
07-12-2012, 10:01 AM
Thibaut Paumard
Recommends for metapackages
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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FFEA089.4090700@free.fr">http://lists.debian.org/4FFEA089.4090700@free.fr
07-12-2012, 10:10 AM
Gergely Nagy
Recommends for metapackages
Andreas Tille <andreas@an3as.eu> 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87ipdtthm2.fsf@algernon.balabit
07-12-2012, 10:17 AM
Gergely Nagy
Recommends for metapackages
Thibaut Paumard <mlotpot.news@free.fr> 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87ehohthas.fsf@algernon.balabit
Recommends for metapackages
