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 configuat
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 configua
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 fu
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 f
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.
>
> Seems like a great idea to me.
>
> If the BTS had a "security" tag, then this c
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.
>
> Seems like a great idea to me.
>
> If the BTS had a "security" tag, then this c
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 unst
> 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 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 preven
> > 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'
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 maint
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 uns
> 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 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 preve
> > 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'
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 main
hat 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 packages that are currently installed on your system.
>
> Is that possible? Would the security
hat 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 packages that are currently installed on your system.
>
> Is that possible? Would the security
dated 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
tas
dated 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
tas
20 matches
Mail list logo
