[Mageia-dev] Mirror layout, round two

Mon Nov 29 23:20:20 CET 2010

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.
+
+