Re: conflicts-based solution (was Re: security in testing)
On Thu, May 15, 2003 at 05:19:17PM +0200, Matthias Urlichs wrote:
> Hi, Sven Luther wrote:
>
> > On Thu, May 15, 2003 at 10:26:35PM +1000, Anthony Towns wrote:
> >> No, it's sitting there, waiting for someone to use it. After a year's
> >> neglect it might need some metaphorical oil on its hinges and some
> >> dusting, but it really is there. I'm not just saying this for
> >> rhetorical value.
> >
> That's great, However...
>
> > [ list of questions / possible problems ]
>
> My impression is that t-p-o is intended to be used like woody-p-o, i.e.
> security fixes only, with a MNUish version number.
So if 1.2.3-4 is in testing, we upload 1.2.3-4.1.sarge ?
> > So, the right and easy solution for the samba security bug is to upload
> > the source package to testing-proposed-update, and it will get rebuild
> > on all testing supported architectures in time.
> >
> Is that automatic, or does somebody have to push a few buttons?
Anthony claims that it is automatic, i have not tested it yet, and had
to rebuild a package myself some time ago, but that was for
woody-proposed-updates, and only on some architectures.
> > What happens then, will it stay apart, or get transitioned into testing
> > when all arches have rebuilt ?
> >
> IMHO: The latter.
>
> > Also, should we use this only for security fixes, or also for other RC
> > bugs or even non RC bugs ? Where is the limit and if there is one, who
> > will enforce it ?
> >
> IMHO the automatic system should make sure that the version number of the
> t-p-o package is between that of the current testing version and that of
> the current unstable, to ensure that the package will eventually be
> replaced with the one in unstable.
Yes.
> Also IMHO, a good rule-of-thumb is "security fix, OR it fixes an important
> bug AND the regular update into testing is stalled".
Ok with me, altough this could be used to work around some of the more
important stalls.
> The automatic system should make sure that testing itself doesn't get
> hosed; it already does that job for unstable. I would like to propose one
> modification, in that the resulting binary packages need to be able to get
> from t-p-o to testing on their own, otherwise they're deleted.
What about multiple packages that are interdependent and are uploadoaded
with a few days (or hours or minutes) interval ?
> Developers' laziness should make sure that the system isn't abused for
> spurious pseudo-updates. ;-)
But then, they could decide to upload to testing-proposed-update only,
and forget about unstable ...
Friendly,
Sven Luther
Reply to: