And it would be great if someone provided a workaround in the meantime
(what currently needs to be done to hold a package in _all_ Debian package
management utilities)?
On Mon, Oct 31, 2011 at 9:37 AM, anatoly techtonik wrote:
> On Mon, Oct 31, 2011 at 7:24 PM, Christian PERRIER
> wrote:
> > Quo
On Mon, Oct 31, 2011 at 7:24 PM, Christian PERRIER wrote:
> Quoting anatoly techtonik (techto...@gmail.com):
>> Why is it so hard to fix this, i.e. to teach aptitude update apt-get
>> structures for packages that aptitude puts on hold?
>>
>> This inconsistency is already causing troubles with SCM
Quoting anatoly techtonik (techto...@gmail.com):
> Why is it so hard to fix this, i.e. to teach aptitude update apt-get
> structures for packages that aptitude puts on hold?
>
> This inconsistency is already causing troubles with SCM tools.
> http://trac.mcs.anl.gov/projects/bcfg2/ticket/1066
>
>
Why is it so hard to fix this, i.e. to teach aptitude update apt-get
structures for packages that aptitude puts on hold?
This inconsistency is already causing troubles with SCM tools.
http://trac.mcs.anl.gov/projects/bcfg2/ticket/1066
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.
Was this ever resolved? Is a "aptitude hold" honored by all other Debian
package utilities?
Package: aptitude
Version: 0.4.4-4
Followup-For: Bug #146207
Hi,
it looks like aptitude upgrade is now considering the hold flag set with dpkg,
but dist-upgrade is just ignoring it.
Thanks, Eric
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (990, 'te
Anything new here? This bug is almost 5 years old, and aptitude is still
unusable... at least for dselect users like me. ;-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
This is still present in current aptitude in etch. It works both ways:
aptitude doesn't care about dpkg/dselect settings anyway, and running
aptitude hold/unhold doesn't change dselect database either.
# dpkg --get-selections | grep ^tin
tin hold
# apti
On Tuesday 07 June 2005 20:53, Daniel Burrows wrote:
> Actually, that's not quite true: searching for '~ahold' will show you
> a list of packages that are either "held" in a sticky way or are not
> going to be upgraded because they haven't been selected for upgrade; if
> you manipulate things a l
Frans Pop wrote:
> On Tuesday 07 June 2005 19:52, Daniel Burrows wrote:
>
>> "aptitude hold" should work. aptitude's parsing of the dselect state
>>has been buggy for a while, mainly because I don't use dselect much and
>>the people who do use it don't seem interested in tracking bugs down
>>and
On Tuesday 07 June 2005 11:37 am, Frans Pop wrote:
> On Tuesday 07 June 2005 19:52, Daniel Burrows wrote:
> > "aptitude hold" should work. aptitude's parsing of the dselect state
> > has been buggy for a while, mainly because I don't use dselect much and
> > the people who do use it don't seem i
On Tuesday 07 June 2005 19:52, Daniel Burrows wrote:
> "aptitude hold" should work. aptitude's parsing of the dselect state
> has been buggy for a while, mainly because I don't use dselect much and
> the people who do use it don't seem interested in tracking bugs down
> and sending me a patch :P
it on hold to prevent it
> > > from being upgraded.
>
> ...
>
> > I think this is bug #146207.
>
> Yikes.. been hanging around since 2002. I think the release notes should
> be updated. Is there a workaround? Does using "aptitude hold" put the
> pac
On Tue, 7 Jun 2005, Bill Allombert wrote:
> > The release notes state:
> > If you changed and recompiled a package locally, and didn't rename it or
> > put an epoch in the version, you must put it on hold to prevent it from
> > being upgraded.
...
> I t
14 matches
Mail list logo
