Re: distinguish between "core" and "main"?
On Sun, 2011-06-05 at 18:02 +0200, Harald Dunkel wrote:
> I cannot speak for others, but I don't wait 3 years. I do
> regular updates/upgrades to include the most recent security
> and bug fixes. We've scheduled regular maintenance weekends
> every 3 months for this. Important updates are installed
> immediately.
NOTE: I specifically chose the words "system upgrade", so as to be clear
I'm not including security updates and stability fixes.
So, you want Debian to change its release management to suit you, while
neglecting what is likely its largest userbase. I'm here referring to
users who don't want to do system upgrades every 3 months.
> >> Of course this doesn't make the +29000 packages outside of the
> >> proposed core repository go away. But I think we already agreed to
> >> use testing for installations of "non-core" packages.
> >
> > But it makes them second-class.
>
> They are surely not second-class, they are just not within core/stable.
> Debian already classifies packages in different priorities, to
> be used today when package updates are pushed into testing, for
> example. I just cannot use these priorities in sources.list, _and_ I
> cannot rely upon the packages in today's testing to work with the
> core packages in stable
Hmmm...
> > Also, backports is supposed to fix this
> > anyway. All needed there is volunteers willing to do the work. Why would
> > you want a different scheme?
> >
>
> Because backports is not supported as good as the current
> testing repo. Why have a 3rd repository next to stable and
> testing with a similar package set, instead of keeping an
> eye upon compatibility right from the start?
What do you mean by "backports is not supported as good as the current
testing repo"? Do you mean the packages there are too small in number?
Talking about your proposed scheme, let's assume that the GNU toolchain
would be part of core/stable. Would you agree that keeping it compatible
with the rest of the system means building the rest of the system with
it? That means keeping it hostage and not updating it for a set period
of time. Now what backports does is that you'll use build tools in
stable to build newer software than is available in stable, to avoid
upgrading a "certified stable" base. And this is a compromise between
stability and freshness. If I'm accurate thus far, it means you are
asking for making a backports system the main way of doing Debian, and
neglecting about everyone else. I'm saying this because we can't have a
main/testing system that's built both by a core/stable version of this
toolchain and a main/testing version. Am I missing anything (sorry if
I'm making you repeat yourself)?
Reply to: