You solution just optimizes doing a dist-upgrade. I'd like something that
doesn't require that I do a dist-upgrade so often.
By time-consuming, I didn't particularly mean the amount of time it takes
to download. That can clearly be done in the backround, by cron, etc.
Going through the
Those who choose to run unstable choose to take upon themselves
more responsibility/inconvenience, if they are unwilling to bear that
burden they should not run unstable.
To me this sounds like:
Every single unstable user must track debian-security-announce.
versus:
One unstable user
On Mon, Nov 20, 2000 at 09:21:40AM -0500, Itai Zukerman wrote:
Those who choose to run unstable choose to take upon themselves
more responsibility/inconvenience, if they are unwilling to bear that
burden they should not run unstable.
To me this sounds like:
Every single unstable
-unstable-security-updates' and cause the upgrade of all the
conflicting packages that are currently installed on your system.
Seems like a great idea to me.
If the BTS had a "security" tag, then this could be done
automatically. A quick look through the debian-devel archives, and I
On Sun, Nov 19, 2000 at 12:55:00PM -0700, Mike Fisk wrote:
There doesn't seem to be an automatic way to get all of the unstable
packages necessary to address reported security problems. You either
have to watch the security mailing lists and upgrade individual packages
yourself or do a full
On 00-11-19 Mike Fisk wrote:
[big snip]
Is that possible? Would the security team be willing to maintain such a
pseudo-package?
Something very close to this kind of task package has been discussed
recently on debian-devel and we come to the conclusion that it won't be
helpful or easy to
It would be very helpful if there was a pseudo-package that conflicted
with packages that have known security problems that have been fixed in a
later version. That way one could do a regular 'apt-get install
task-unstable-security-updates' and cause the upgrade of all the
conflicting
On Mon, Nov 20, 2000 at 08:21:10AM -0500, Itai Zukerman wrote:
The answer is just to watch one single list - debian-security-announce.
That's what it's for :)
I'm not sure I understand the reasoning here. If the answer is to
watch the debian-security-announce list, then what prevents
Those who choose to run unstable choose to take upon themselves
more responsibility/inconvenience, if they are unwilling to bear that
burden they should not run unstable.
To me this sounds like:
Every single unstable user must track debian-security-announce.
versus:
One unstable user
On Mon, Nov 20, 2000 at 09:21:40AM -0500, Itai Zukerman wrote:
Those who choose to run unstable choose to take upon themselves
more responsibility/inconvenience, if they are unwilling to bear that
burden they should not run unstable.
To me this sounds like:
Every single unstable user
On Mon, Nov 20, 2000 at 08:21:10AM -0500, Itai Zukerman wrote:
It would be very helpful if there was a pseudo-package that conflicted
with packages that have known security problems that have been fixed in a
later version. That way one could do a regular 'apt-get install
task-unstable
On Sun, Nov 19, 2000 at 12:55:00PM -0700, Mike Fisk wrote:
There doesn't seem to be an automatic way to get all of the unstable
packages necessary to address reported security problems. You either
have to watch the security mailing lists and upgrade individual packages
yourself or do a full
in unstable, that can be prohibitibely bandwidth and
time-consuming.
It would be very helpful if there was a pseudo-package that conflicted
with packages that have known security problems that have been fixed in a
later version. That way one could do a regular 'apt-get install
task-unstable
in unstable, that can be prohibitibely bandwidth and
time-consuming.
It would be very helpful if there was a pseudo-package that conflicted
with packages that have known security problems that have been fixed in a
later version. That way one could do a regular 'apt-get install
task-unstable
. That way one could do a regular 'apt-get install
task-unstable-security-updates' and cause the upgrade of all the
conflicting packages that are currently installed on your system.
Is that possible? Would the security team be willing to maintain such a
pseudo-package?
Not really. Our
15 matches
Mail list logo
