On Sat, 2008-01-12 at 00:40 -0500, Mike Frysinger wrote: > On Friday 11 January 2008, Chris Gianelloni wrote: > > For one, a way to mark a profile as deprecated in profiles.desc so > > repoman doesn't scan it (currently, we remove tend to remove them from > > the list). > > is this really needed ? i'm trying to see why this would be useful, and not > coming up with much ... profiles.desc exists for two reasons: > - for qa tools to scan > - so people have a list of valid profiles > if a profile is deprecated and on the way out, neither of these two things > apply to it, so what's the use of having it listed ? we can already mark > profiles deprecated for users who already have it selected ...
I guess I was thinking more for the package manager. As I said, I would love for it to enforce a valid profile as defined in profiles.desc, even if it is a deprecated one, until the user switches. This means the deprecated profile needs to be listed in profiles.desc, but we don't want to run QA on it, as you said. > > The second would be a change to repoman that's more > > "invasive" in that it changes current behavior a good bit, but having > > repoman only scan "stable" profiles, by default, with options to scan > > the other types. > > i think by moving our most annoying profiles out of the dev to the exp state > would mean that any warnings left while in the dev state are something we > want to be seeing and addressing. the problem right now is that we have two > types of profiles listed in dev: ones that people should care about and > shouldnt be breaking and ones that people shouldnt care about and are free to > break. package maintainers obviously dont (and shouldnt) know which are > which. Indeed. I can see that with the profiles reassigned there's no need for this. > > I've always wanted to have *every* valid profile > > listed in profiles.desc so we can do things like have portage not allow > > someone to use a profile that isn't listed in profiles.desc (of course, > > overlay users crazy enough could do their own profiles.desc and it would > > be stacked with the in-tree one). The main problem with doing this has > > been the effect on repoman, since it scans every listed profile every > > time. I know that most of the profile selection tools out there already > > only show profiles that are listed in profiles.desc, so it wouldn't > > really be a change for them, but I think it would be useful elsewhere, > > too. All in all, having profiles.desc actually showing the status of > > all of the profiles would be great. > > i could see it tied to FEATURES=strict. if you have this enabled, then > you're > only allowed to use declared profiles (which means if you use a non-standard > one, you'd need to declare it). Sure. I see no reason to not allow someone to turn it off. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer
signature.asc
Description: This is a digitally signed message part