© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
(In reply to comment #70)
> (In reply to comment #69)
> > Thinking of comment 68, I could make an interim patch which only adds
> > core/release and core/updates repos to update-tagged repos for updates.
>
> Hardcoding media names is ugly.
Actually it was media paths, required on all the mirrors.
( in fact, media/core/release and media/core/updates )
Can you think of any other way of determining release and update media ?
Pensée magique doesn't work.
> And core/release should not be tagged as
> update, but only used for dependencies.
What I meant to say is adding to active media. My fingers were temporarily disengaged from my brain :-P
> And there is no reason to only use
> those medias when there are other active medias.
That is not at all what I proposed.
Don't forget policy is that updates should use release and update media for dependancies. So what is the problem with adding such media ?
> So I can't see any good reason for doing this.
>
> We already have a very simple patch to use all active medias for dependencies,
> and I don't see any reason not to use it.
Of course, the simple patch would allow a core package with nonfree dependancies, for example.
Would that help QA catch such errors ?
Or a core package with tainted dependancies.
Or a tainted package with nonfree dependancies, etc.
I was just trying to suggest an option that would help QA short-term without opening any loop-holes.
BTW, I'm not sure that we really should accept just any active media for update dependancies, instead of only the official mageia release and update medias.
Since if QA testers have other active media during testing, errors in dependancies could be ignored.
However if we decide to make this restriction, then local repos would have to have the same terminating directory structure to be used.
But the restriction isn't necessary if QA is always careful to ensure that no other media are active. (Or only those limited to packages in official media.)
But when it comes to backports, most testing will be done by non-QA users, where such a restriction would be useful.