On Mon, 29 Nov 2010, andre999 wrote: > They focus on the issue in question, to varying degrees of success. > (Reminds me of end-user support. Much of the time they don't recognize the > real problem.) > My point is, significant bugs in core packages should be fixed in a timely > manner, as much as possible. And indeed, critical bugs should be fixed. > But if a critical bug affects a non-core package, it is likely to affect > only that package. Not so a core bug.
I would expect package maintainers to know wether the packages they maintain are critical or not by themself. I don't think it would make sense to look at the repository name to decide if it's a critical bug or not. >>> Core is proposed to be largely "base system& components". Part of the >>> idea is to make clearer, to everyone, which packages have an enhanced level >>> of support. >>> Support time is another (useful) question. >>> >> Why do we need two repositories for that ? >> > Sandbox. > It is clearer to everyone. How is that "clearer" ? The level of support is not even displayed in current versions of rpmdrake. And you have to click on "Details" to see the repository name. If we provide the list of fully supported packages separatly, we could display the level of support in the package manager. How would that be "less clear to everyone" ? > The fact that Mandriva didn't control what went into main is a large part > of their problem. Mandriva controled what went into main. > If you can find another solution, just as reliable, great. > But I suspect it would be more complex, and probably cost more in resources > as well. > The cost of extra repositories is almost nil - if we assume that we want to > rigorously control what is to be fully supported, and apply it. As already explained in this thread, the cost is not nil, and we don't need repositories to define what is fully supported. >>>> - Some packages have a lot of optional plugins, and we build them all, >>>> adding a lot of build requires. With main/contrib separation we need >>>> to add all the build dependencies to main, even if most of them are >>>> not runtime dependencies. >>>> >>> We will have to be more selective for core packages, to avoid this problem. >>> Maybe "suggests", or other features being added with rpm5. >>> >> Suggests on BuildRequires does not exists. And we need them to be >> installed for the build. >> > If a core package has real buildrequires, then these requires should be in > core. What is "real buildrequires" ? > If only a non-core package has buildrequires, these requires need not > necessarily be in core. > Although packages like cmake should probably be in core anyway, as they are > very likely to be used to build packages. > I don't know details for rpm5, but it could have the equivalent of suggests > for buildrequires. (Like an alternate list of tools required ?) Suggests for buildrequires doesn't make much sense.
