[gentoo-dev] extend profiles.desc to include "experimental" profiles
Mike Frysinger
a new state for profiles.desc. the new field would simply be "exp" to
indicate that the profile is experimental and that qa tools should generally
not issue warnings about them. so in repoman's default mode, you wouldnt get
any warnings, but if you were to run it in full mode, you'd see stuff like
normal. this is useful for new projects which are still in the process of
merging (like *-fbsd, m68k, and any new hardware i get my hands on) and are
not really ready for "dev" marking. there are plenty of warnings in packages
right now due to these profiles being labeled as "dev" that are the sole
problem of the keyword maintainer in question and not the package maintainer.
-mike
Doug Klima
profiles in profiles.desc. This sounds very reasonable and logical. And
hopefully if the tools in question are coded properly, it should be
compatible with older versions until users upgrade.
Good stuff Mike.
--
Doug Klima
Gentoo Developer
--
gento...@lists.gentoo.org mailing list
Chris Gianelloni
To go along with this, I've always wanted a few other minor changes.
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). 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'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.
> Good stuff Mike.
Indeed.
--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
Mike Frysinger
> 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 ...
> 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.
> 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).
-mike
Chris Gianelloni
> 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.