Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-30 Thread Petter Reinholdtsen 

[Frans Pop]
> Not really as these issues generally only occur when packages are
> being *upgraded* using 'aptitude install ', not when they
> are being newly installed.

Sure, they might not happen a lot, but they also happen from within
debian-installer.  With Debian Edu/Squeeze, I recently noticed one
example, where jackd fail to install using aptitude, but install just
fine with apt-get, because the latter seem to do a better job at
finding a installable set based on the packages tasksel want to
install. :)

> For tasksel that would destroy the option to review which packages
> get installed, which is an important option when tasksel is invoked
> manually (I've used it for example to determine task sizes for the
> Installation Guide).

How come?  I would expect the method described in
http://people.skolelinux.org/pere/blog/Calling_tasksel_like_the_installer__while_still_getting_useful_output.html
 >
would work with both apt-get and aptitude.

> I suspect you are wrong. apt-install does not use aptitude, but
> pkgsel does.

OK.  I trust you to know this better than me, but it is a bit besides
my point, which is that it is fairly small change to replace aptitude
with apt-get in d-i.  I would believe it would be better for d-i to
use the same tool in the installer, for predictability and
consistency, as well as to keep the dependencies down.

Sure, it will give change the behaviour of d-i, but that is also the
point, if the aptitude behaviour is worse than that of apt-get. :)

Happy hacking,
-- 
Petter Reinholdtsen
Pretending d-i developer


-- 
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/2fl4ofg250d@login2.uio.no

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-30 Thread Frans Pop 
Petter Reinholdtsen wrote:
> [Steve Langasek]
>> Not only is apt-get now strong enough to handle the cases for which we
>> recommended aptitude in the sarge timeframe (with much better resolution
>> of upgrades, installation of Recommends by default, and tracking of
>> auto-installed packages), but aptitude has also had several deplorable
>> regressions since etch.  I don't know which of these made it into the
>> lenny release or which are still present in squeeze, but:
>>
>>   - When I type 'aptitude install foo', *removing* foo instead of
>> upgrading is not a valid solution and should never be offered.
>>   - When I type 'aptitude install foo', installing 5 packages, removing
>> 3 others, and upgrading 7 more *without installing foo* is not a
>> valid solution and should never be offered.
> 
> If these are present, they sound like good arguments for changing
> tasksel to use apt-get instead of aptitude.

Not really as these issues generally only occur when packages are being 
*upgraded* using 'aptitude install ', not when they are being 
newly installed.
When upgrading the issues will also occur more frequently if packages are 
broken (e.g. when upgrading in unstable) than when they are installable.

I don't think these issues are all that relevant in the D-I context.

>> I believe the correct recommendations would be:
>>
>>   - apt-get for all commandline operations, including package
>>   installation and removal, and dist-upgrades
> 
> I assume you mean all over debian-installer too?  The apt-install
> script would have to change, as well as tasksel.

For tasksel that would destroy the option to review which packages get 
installed, which is an important option when tasksel is invoked manually 
(I've used it for example to determine task sizes for the Installation 
Guide).

Please make very sure you don't introduce regressions or loss of 
functionality when considering such changes.

> I suspect those two are the only ones using apt-get or aptitude
> directly in debian-installer.

I suspect you are wrong. apt-install does not use aptitude, but pkgsel 
does. Is it really so hard to check (grep) the D-I source before writing 
such mails, especially when pretending to be a D-I developer?

Cheers,
FJP


-- 
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/201007301305.59555.elen...@planet.nl

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-30 Thread Petter Reinholdtsen 

[Steve Langasek]
> Not only is apt-get now strong enough to handle the cases for which we
> recommended aptitude in the sarge timeframe (with much better resolution of
> upgrades, installation of Recommends by default, and tracking of
> auto-installed packages), but aptitude has also had several deplorable
> regressions since etch.  I don't know which of these made it into the lenny
> release or which are still present in squeeze, but:
>
>   - When I type 'aptitude install foo', *removing* foo instead of upgrading
> is not a valid solution and should never be offered.
>   - When I type 'aptitude install foo', installing 5 packages, removing 3
> others, and upgrading 7 more *without installing foo* is not a valid
> solution and should never be offered.

If these are present, they sound like good arguments for changing
tasksel to use apt-get instead of aptitude.

> I believe the correct recommendations would be:
>
>   - apt-get for all commandline operations, including package installation
> and removal, and dist-upgrades

I assume you mean all over debian-installer too?  The apt-install
script would have to change, as well as tasksel.  I suspect those two
are the only ones using apt-get or aptitude directly in
debian-installer.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/2flhbjh1evq@login2.uio.no

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-18 Thread Michael Banck 
On Thu, Jul 15, 2010 at 11:13:11PM -0500, Steve M. Robbins wrote:
> So while raising Boost will "solve" the issue, it seems to me to be
> a recipe for runaway priority inflation.
> 
> Is there any central authority to vet priority changes?

Indeed, I think this needs wider attention, next to the
apt-get-vs.-aptitude discussion.

I believe additional Depends on important packages should get proposed
on -devel first, so that people can comment on them and possibly
propose alternatives etc.


Michael


-- 
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/20100718132042.ga17...@nighthawk.chemicalconnection.dyndns.org

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-18 Thread Jonathan Wiltshire 
On Sun, Jul 18, 2010 at 02:38:50AM +0200, Steve Langasek wrote:
> 
>   - When I type 'aptitude install foo', *removing* foo instead of upgrading
> is not a valid solution and should never be offered.

It's still an outstanding (and irritating) bug as late as yesterday's
sid...


-- 
Jonathan Wiltshire

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


signature.asc
Description: Digital signature

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-18 Thread Steve Langasek 
On Fri, Jul 16, 2010 at 11:59:45AM +0200, Frans Pop wrote:
> Steve Langasek wrote:
> > This manual represents the opinion of a single developer.

> And what does that have to do with the price of bananas in Iceland?

> The fact that aptitude is currently the recommended tool for package 
> management has various reasons: user interface, features, dependency 
> handling, etc. That status has evolved over the last 3 or so release 
> cycles. You have even been part of some of the discussions (for example 
> sarge -> etch upgrade issues)

"Dependency handing" is certainly not a reason to recommend aptitude.

Yes, I was part of the discussions recommending it for release upgrades in
the sarge and etch timeframe.  For lenny, I strongly counseled *against*
recommending aptitude for release upgrades, due to some concrete regressions
in aptitude's upgrade handling at the same time that apt itself had reached
parity on all the relevant features (improved upgrade resolver; Recommends
handling).  It remained in the release notes anyway owing to concerns that
it was too late in the cycle to get good tester feedback on upgrades using
apt-get, but I intend to again advise removing aptitude from the squeeze
release notes in favor of apt-get.  aptitude's resolver is just too
inconsistent and has too many pathological edge cases for it to be a good
idea to recommend its use as a dist-upgrader.

Now for interactive upgrades, aptitude does have the best interface.  But it
doesn't follow that it should be Priority: important as a result; there are
any number of packages that we may recommend for one purpose or another that
nevertheless shouldn't be installed as 'important'.

> aptitude is the primary tool used by Debian Installer (and because of that 
> its current priority of "important" is actally necessary).

This is the only reason I see that it should be 'important'.  I'm not (yet)
convinced that this is necessary.  Some alternatives would seem to be:

  - opportunistically install aptitude when a user wants fine-grained
package selection in the installer; otherwise only install it when the
'standard' task is selected.  (Downside: user has to wait for aptitude
to be installed, introducing delay at another point in the installer.)
  - have the installer special-case the automatic installation of aptitude in
spite of not being Priority: important, so that it's available at the
right point in the installer. (Downside: special-casing; and if the user
doesn't select the standard task, we either uninstall it at the end of
the install leaving users without access to this interface post-install,
or we leave it on everybody's system anyway, in which case it might as
well just be Priority: important.)

These are some other options to think about, but on balance, I would
conclude that raising the priority of libboost-iostreams to important is
actually the right solution.  Boost is an annoyingly unstable library to
depend on and its library transitions are painful, but most of the
individual component libraries (including libboost-iostreams) are actually
quite small with no unusual dependencies; and raising one of these
components to important shouldn't cause any problems.

> It is also recommended in both the Release Notes (for stable release
> upgrades) and the Installation Guide.

The first of these is a bug that needs fixed.  The second is a reasonable
recommendation if we're pointing users at the TUI; for the CLI we should
simply recommend apt-get.

> So what's listed in the "Debian Reference" is a correct reflection of 
> aptitude's current status and not, as you imply, the result of some single 
> developer being on crack.

Right, it's the result of several developers being on crack. :-P
Regardless of whether there are other developers who agree with this
particular opinion (which, for any given opinion, is bound to be the case),
I think it's important to distinguish between documents whose drafting is
done on open mailing lists and whose recommendations are the result of
consensus (Debian Policy; DevRef, now that it's on debian-policy;
Installation Guide; Release Notes) and those that are maintained by
individuals.  The latter are useful, but are not the word of the Project.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
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/20100718001852.ga3...@dario.dodds.net

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-18 Thread Steve Langasek 
On Thu, Jul 15, 2010 at 09:17:38PM -0700, Russ Allbery wrote:
> > I wouldn't place any of Boost in that category.  In fact, I wouldn't
> > place "aptitude" in that category, either.

> aptitude was historically the recommended tool to use for upgrades because
> it had the best dependency resolver for handling the dist-upgrade case.
> For so long as that's true, it should be priority: important, which means
> that by definition the things that it requires are also priority:
> important or higher.

> If apt-get is now strong enough that we can recommend it for upgrades
> without qualms, then aptitude is another alternative package manager and
> standard may be fine.  Is that now the case?

Not only is apt-get now strong enough to handle the cases for which we
recommended aptitude in the sarge timeframe (with much better resolution of
upgrades, installation of Recommends by default, and tracking of
auto-installed packages), but aptitude has also had several deplorable
regressions since etch.  I don't know which of these made it into the lenny
release or which are still present in squeeze, but:

  - When I type 'aptitude install foo', *removing* foo instead of upgrading
is not a valid solution and should never be offered.
  - When I type 'aptitude install foo', installing 5 packages, removing 3
others, and upgrading 7 more *without installing foo* is not a valid
solution and should never be offered.

And the reason I don't know if these regressions are still present in lenny
or squeeze is that, after about the second time running into such issues, I
abandoned use of aptitude altogether.  It's one thing to be unable to find a
solution and throw me an error; I have no patience for tools that do
something other than what I tell them to.

On Sat, Jul 17, 2010 at 12:43:05AM +0900, Osamu Aoki wrote:

> > Though I think any manual published on debian.org recommending aptitude for
> > upgrades is a bug that should be fixed.

> I fail to understand your intent of this statement.  

> Are you suggesting me to change the following text? 

>   Aptitude is the current preferred package management tool for the
>   Debian system. 

Yes, I believe this text should be changed.

> How does it need to be changed?  I am very curious and open for
> suggestion.

I believe the correct recommendations would be:

  - apt-get for all commandline operations, including package installation
and removal, and dist-upgrades
  - aptitude for an interactive text interface for managing the installed
packages
  - update-manager for keeping your system up-to-date if you're running the
default GNOME desktop.

> Please note this document[1] is claimed to be a secondary documentation.
> I am merely following the primary documentation:
> http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgradingpackages

> | Release Notes for Debian GNU/Linux 5.0 (lenny)
> |
> | 4.5. Upgrading packages
> | 
> | The recommended way to upgrade from previous Debian GNU/Linux releases
> | is to use the package management tool aptitude. This program makes safer
> | decisions about package installations than running apt-get directly. 

> As I recall, there were long active discussion to reach this text.  So
> at least, this assessment is not an opinion of a single developer.

Two things:

 - This is a recommendation to use it as a tool for upgrading from previous
   releases, and is not an endorsement of the tool as a "preferred" package
   manager for other operations.  The upgrade instructions in the release
   notes are carefully crafted to try to smoothly and correctly handle
   upgrades on as many users' systems as possible, and for that reason,
   solutions should be considered for each release that use tools other than
   those recommended for daily operations.

 - The recommendation in the release notes was correct /at the time it was
   drafted/ (i.e., for sarge).  By lenny, it was giving noticeably worse
   results than apt-get in many cases, but by the time the issue was raised,
   some felt it was too late in the release cycle to revisit the text.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-17 Thread Marc Haber 
On Thu, 15 Jul 2010 23:29:10 -0700, Steve Langasek 
wrote:
>Though I think any manual published on debian.org recommending aptitude for
>upgrades is a bug that should be fixed.

Why?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1oa35p-0001kg...@swivel.zugschlus.de

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-16 Thread Osamu Aoki 
Hi,

On Thu, Jul 15, 2010 at 11:29:10PM -0700, Steve Langasek wrote:
> On Fri, Jul 16, 2010 at 12:59:56AM -0400, Will wrote:
> > aptitude is the preferred package management tool, so I'm thinking
> > that the priority of libboost-iostreams should be upgraded [1][2].
> 
> > [1] 
> > http://www.debian.org/doc/manuals/reference/ch02.en.html#_basic_package_management_operations
> 
> This manual represents the opinion of a single developer.  It has not been
> ratified by the Debian project, and individual recommendations made within
> should not be taken for the preferences of the Debian project.

I can agree up to here.

> Though I think any manual published on debian.org recommending aptitude for
> upgrades is a bug that should be fixed.

I fail to understand your intent of this statement.  

Are you suggesting me to change the following text? 

  Aptitude is the current preferred package management tool for the
  Debian system. 

How does it need to be changed?  I am very curious and open for
suggestion.

Please note this document[1] is claimed to be a secondary documentation.
I am merely following the primary documentation:
http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgradingpackages

| Release Notes for Debian GNU/Linux 5.0 (lenny)
|
| 4.5. Upgrading packages
| 
| The recommended way to upgrade from previous Debian GNU/Linux releases
| is to use the package management tool aptitude. This program makes safer
| decisions about package installations than running apt-get directly. 

As I recall, there were long active discussion to reach this text.  So
at least, this assessment is not an opinion of a single developer.

Osamu


-- 
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/20100716154305.gb3...@debian.org

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-16 Thread Frans Pop 
Steve Langasek wrote:
> This manual represents the opinion of a single developer.

And what does that have to do with the price of bananas in Iceland?

The fact that aptitude is currently the recommended tool for package 
management has various reasons: user interface, features, dependency 
handling, etc. That status has evolved over the last 3 or so release 
cycles. You have even been part of some of the discussions (for example 
sarge -> etch upgrade issues)

aptitude is the primary tool used by Debian Installer (and because of that 
its current priority of "important" is actally necessary). It is also 
recommended in both the Release Notes (for stable release upgrades) and 
the Installation Guide.

So what's listed in the "Debian Reference" is a correct reflection of 
aptitude's current status and not, as you imply, the result of some single 
developer being on crack.

The growing dependency chain of aptitude *is* of some concern and may be 
reason to re-evaluate its role, but in no way does that change its 
_current_ status.

Cheers,
FJP


-- 
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/201007161159.47593.elen...@planet.nl

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-15 Thread Steve Langasek 
On Fri, Jul 16, 2010 at 12:59:56AM -0400, Will wrote:
> aptitude is the preferred package management tool, so I'm thinking
> that the priority of libboost-iostreams should be upgraded [1][2].

> [1] 
> http://www.debian.org/doc/manuals/reference/ch02.en.html#_basic_package_management_operations

This manual represents the opinion of a single developer.  It has not been
ratified by the Debian project, and individual recommendations made within
should not be taken for the preferences of the Debian project.

Though I think any manual published on debian.org recommending aptitude for
upgrades is a bug that should be fixed.

> [2] http://wiki.debian.org/Aptitude

Well, and this is a page in a wiki about aptitude.  The existence of such a
page is not a recommendation by the Debian project that it should be used.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-15 Thread Will 
6, 2010 at 12:17 AM, Russ Allbery  wrote:
> "Steve M. Robbins"  writes:
>
>> I wouldn't place any of Boost in that category.  In fact, I wouldn't
>> place "aptitude" in that category, either.
>
> aptitude was historically the recommended tool to use for upgrades because
> it had the best dependency resolver for handling the dist-upgrade case.
> For so long as that's true, it should be priority: important, which means
> that by definition the things that it requires are also priority:
> important or higher.
>
> If apt-get is now strong enough that we can recommend it for upgrades
> without qualms, then aptitude is another alternative package manager and
> standard may be fine.  Is that now the case?
>
> --
> Russ Allbery (r...@debian.org)               
>
>
> --
> 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/87y6dc83h9@windlord.stanford.edu
>
>

aptitude is the preferred package management tool, so I'm thinking
that the priority of libboost-iostreams should be upgraded [1][2].
aptitude has more features than just a better dependency handler, like
the significantly more advanced search syntax and the smarter,
interactive resolver. I think the better decision is to edit it such
that it doesn't require that library. However, that's a decision for
the aptitude team to make, since I have no idea how heavily it relies
on that package, or what portions of the program depend on that
library.

I'd be glad to donate some of my time if the aptitude team wanted it though.

[1] 
http://www.debian.org/doc/manuals/reference/ch02.en.html#_basic_package_management_operations
[2] http://wiki.debian.org/Aptitude

-- 
-Will Orr


--
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/aanlktin94w_6n-zwytv_qpkkaoihgrxqs2qn8g00b...@mail.gmail.com

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-15 Thread Russ Allbery 
"Steve M. Robbins"  writes:

> I wouldn't place any of Boost in that category.  In fact, I wouldn't
> place "aptitude" in that category, either.

aptitude was historically the recommended tool to use for upgrades because
it had the best dependency resolver for handling the dist-upgrade case.
For so long as that's true, it should be priority: important, which means
that by definition the things that it requires are also priority:
important or higher.

If apt-get is now strong enough that we can recommend it for upgrades
without qualms, then aptitude is another alternative package manager and
standard may be fine.  Is that now the case?

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87y6dc83h9@windlord.stanford.edu

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

2010-07-15 Thread Steve M. Robbins 
Folks,

The package "aptitude" is priority "important" and depends on
libboost-iostreams, which is "optional".  This is a violation of
Policy section 2.5.

The request of Bug #588608 is to raise the priority of
libboost-iostreams to "important".  Reading Policy, I note that
"important" means:

 `important'
  Important programs, including those which one would expect to
  find on any Unix-like system.  If the expectation is that an
  experienced Unix person who found it missing would say "What on
  earth is going on, where is `foo'?", it must be an `important'
  package.[1] Other packages without which the system will not run
  well or be usable must also have priority `important'.  This does
  _not_ include Emacs, the X Window System, TeX or any other large
  applications.  The `important' packages are just a bare minimum
  of commonly-expected and necessary tools.

I wouldn't place any of Boost in that category.  In fact, I wouldn't
place "aptitude" in that category, either.

So while raising Boost will "solve" the issue, it seems to me to be
a recipe for runaway priority inflation.

Is there any central authority to vet priority changes?

Thanks,
-Steve


signature.asc
Description: Digital signature