[gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

Hi Guys,

Before dberholz complains about my next commit, given that we have
support in profiles for package.use, how soon can we start to use it to
replace the old crufty no* flags (particularly ones that are critical to
a system).

One of the ones I've got in my sights is USE=nolvmstatic of sys-fs/lvm2.
It exists because we default to building LVM as static because it gets
included into the genkernel init environment (ultimately it should be
built by genkernel directly, but that's a different issue).

To implement it, I'd be adding this entry to profiles/base/package.use:
# Build a static LVM by default, for genkernel usage
sys-fs/lvm2 static

Likewise, USE='nolvm1' can change to 'USE=lvm1', and be included in
package.use.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]

Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[Jason Smathers]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

On 10/2/07, Robin H. Johnson <robbat2@gentoo.org> wrote:
>
> Hi Guys,
>
> Before dberholz complains about my next commit, given that we have
> support in profiles for package.use, how soon can we start to use it to
> replace the old crufty no* flags (particularly ones that are critical to
> a system).


I like the default use flag solution, which seems to be introduced with
portage 2.1.2.  This way you can replace nofoo with foo and
IUSE="+foo" if you want it to default on.

When will the portage 2.1.0 and 2.1.1 ebuilds will be dropped?

With either solution, when updating existing ebuilds, how do you alert
users that they must change use flag nofoo to -foo if they want to
maintain nofoo functionality?

Regards,
Jason Smathers

[-- Attachment #2: Type: text/html, Size: 1074 bytes --]

Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Smathers wrote:
> On 10/2/07, *Robin H. Johnson* <robbat2@gentoo.org
> <mailto:robbat2@gentoo.org>> wrote:
> 
>     Hi Guys,
> 
>     Before dberholz complains about my next commit, given that we have
>     support in profiles for package.use, how soon can we start to use it to
>     replace the old crufty no* flags (particularly ones that are
>     critical to
>     a system).
> 
> 
> I like the default use flag solution, which seems to be introduced with
> portage 2.1.2.  This way you can replace nofoo with foo and
> IUSE="+foo" if you want it to default on.

Given that >=sys-apps/portage-2.1.2 has been stable since February,
and it's included in the 2007.0 release media, I think it's pretty
safe to start using package.use in profiles.

As for using things like IUSE defaults and SLOT dependencies in
ebuilds (both supported by portage-2.1.2), the most backward
compatible approach is to do an EAPI bump. We should probably
include a few other things in the EAPI-1 bump [1] that aren't
implemented yet. We don't have to include everything that's planned,
but it would be good to include at least some of the simplest features.

It's also possible to skip the EAPI bump for some of the implemented
features and redefine EAPI-0 to include them, but that has backward
incompatibility repercussions for users that lag months (or years)
behind in updates. The negative impact of this approach lessens as
the time since portage-2.1.2 stabilization increases.

> When will the portage 2.1.0 and 2.1.1 ebuilds will be dropped?

The old ebuilds are kept only as an upgrade path from older versions
of python. People shouldn't use them for anything more than that.

> With either solution, when updating existing ebuilds, how do you alert
> users that they must change use flag nofoo to -foo if they want to
> maintain nofoo functionality?

One possible solution is for the ebuilds to support both flags
during a migration period. If the ebuild detects that a deprecated
flag is enabled, then it can issue an ewarn or eerror message to
notify the user.

Zac

[1] https://bugs.gentoo.org/show_bug.cgi?id=174380
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHAsZh/ejvha5XGaMRAghaAKDts+vXjyT3lqvR4QpGeUkR7a3pYACghgp0
XJFYeIG5CIQQKINzxtqHyXo=
=iE9X
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Getting rid of lurking no* USE flags - profile-based package.use

[Ryan Hill]

Zac Medico wrote:
> Jason Smathers wrote:
>> On 10/2/07, *Robin H. Johnson* <robbat2@gentoo.org
>> <mailto:robbat2@gentoo.org>> wrote:
> 
>>     Hi Guys,
> 
>>     Before dberholz complains about my next commit, given that we have
>>     support in profiles for package.use, how soon can we start to use it to
>>     replace the old crufty no* flags (particularly ones that are
>>     critical to
>>     a system).
> 
> 
>> I like the default use flag solution, which seems to be introduced with
>> portage 2.1.2.  This way you can replace nofoo with foo and
>> IUSE="+foo" if you want it to default on.
> 
> Given that >=sys-apps/portage-2.1.2 has been stable since February,
> and it's included in the 2007.0 release media, I think it's pretty
> safe to start using package.use in profiles.
> 
> As for using things like IUSE defaults and SLOT dependencies in
> ebuilds (both supported by portage-2.1.2), the most backward
> compatible approach is to do an EAPI bump. We should probably
> include a few other things in the EAPI-1 bump [1] that aren't
> implemented yet. We don't have to include everything that's planned,
> but it would be good to include at least some of the simplest features.

SLOT depends are something we could really use right now.  What kind of
time frame are you thinking of?

-- 
                  fonts / wxWindows / gcc-porting / treecleaners
  9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Getting rid of lurking no* USE flags - profile-based package.use

[Rémi Cardona]

Ryan Hill wrote:
> SLOT depends are something we could really use right now.  What kind of
> time frame are you thinking of?

+1 from the Gnome Herd, we could definitely use them as well (glib, gtk,
gtkhtml, gtksourceview, ... are all slotted)

Rémi
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Getting rid of lurking no* USE flags - profile-based package.use

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ryan Hill wrote:
> Zac Medico wrote:
>> As for using things like IUSE defaults and SLOT dependencies in
>> ebuilds (both supported by portage-2.1.2), the most backward
>> compatible approach is to do an EAPI bump. We should probably
>> include a few other things in the EAPI-1 bump [1] that aren't
>> implemented yet. We don't have to include everything that's planned,
>> but it would be good to include at least some of the simplest features.
> 
> SLOT depends are something we could really use right now.  What kind of
> time frame are you thinking of?

Trying to include things that aren't implemented or things that are
controversial will delay it. It's difficult to make time estimates
for anything that's not implemented yet.

It's trivial to do the EAPI-1 bump if we only include things that
are already implemented.  I can have a sys-apps/portage release in
the tree this week with EAPI-1 support if we choose to do that.
Looking at bug #174380, I'd say that EAPI-1 should certainly include
#174405, #174410, and #179380 since they're all implemented and
relatively non-controversial. Anything more than those can lead to
potential delays.

Zac

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHA8VV/ejvha5XGaMRAjVmAKDYi/BX6HU/v8B0Mf8l6qfschmyjgCfbBdq
cj2yldMRM+saK8KnKKi7UF4=
=+efu
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Getting rid of lurking no* USE flags - profile-based package.use

[Donnie Berkholz]

On 09:37 Wed 03 Oct     , Zac Medico wrote:
> Trying to include things that aren't implemented or things that are
> controversial will delay it. It's difficult to make time estimates
> for anything that's not implemented yet.
> 
> It's trivial to do the EAPI-1 bump if we only include things that
> are already implemented.  I can have a sys-apps/portage release in
> the tree this week with EAPI-1 support if we choose to do that.
> Looking at bug #174380, I'd say that EAPI-1 should certainly include
> #174405, #174410, and #179380 since they're all implemented and
> relatively non-controversial. Anything more than those can lead to
> potential delays.

Alright, do it! =) "Release early, release often" applies to EAPI too.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Getting rid of lurking no* USE flags - profile-based package.use

[Ryan Hill]

Zac Medico wrote:
> Ryan Hill wrote:
>> SLOT depends are something we could really use right now.  What kind of
>> time frame are you thinking of?
> 
> Trying to include things that aren't implemented or things that are
> controversial will delay it. It's difficult to make time estimates
> for anything that's not implemented yet.
> 
> It's trivial to do the EAPI-1 bump if we only include things that
> are already implemented.  I can have a sys-apps/portage release in
> the tree this week with EAPI-1 support if we choose to do that.
> Looking at bug #174380, I'd say that EAPI-1 should certainly include
> #174405, #174410, and #179380 since they're all implemented and
> relatively non-controversial. Anything more than those can lead to
> potential delays.

Yes please.  ;P  I think doing small incremental bumps would be better
than trying to stuff everything in at once.  Doing it now would also
give us a sense of what to expect in future, more invasive EAPI changes.

-- 
                  fonts / wxWindows / gcc-porting / treecleaners
  9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[Jim Ramsay]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

"Robin H. Johnson" <robbat2@gentoo.org> wrote:
> how soon can we start to use it
> to replace the old crufty no* flags

So what's going on here?  Do we need to wait for EAPI=1 and use the new
IUSE defaults?  Or can we use package.use right now?

I also have some 'disablefoo' USE flags I want to clear out for the
1.0.0 release of fluxbox.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Ramsay wrote:
> "Robin H. Johnson" <robbat2@gentoo.org> wrote:
>> how soon can we start to use it
>> to replace the old crufty no* flags
> 
> So what's going on here?  Do we need to wait for EAPI=1 and use the new
> IUSE defaults?  Or can we use package.use right now?

I think it's OK to start using package.use now considering that
package.use has been supported since portage-2.1.2 and that's been
stable since February. There are already a couple of packages using
it in the tree now.

Zac


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHDC59/ejvha5XGaMRAgrmAJ4pDB143kdDUmONUP+K4zMUe+odOwCdGuxv
AZ2l40GfjZCs9Urm04iNb1k=
=11//
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[Denis Dupeyron]

On 10/10/07, Zac Medico <zmedico@gentoo.org> wrote:
> I think it's OK to start using package.use now considering that
> package.use has been supported since portage-2.1.2 and that's been
> stable since February. There are already a couple of packages using
> it in the tree now.

Is it a good idea for those ebuilds that require new features to have
a >= dependency on a specific version of portage ? Or not ? Can this
help when switching EAPIs ? Or plug the gap while the decision to
switch to EAPI=1 is being taken ? Does /me need more coffee or a good
clue-batting session ?

Denis.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denis Dupeyron wrote:
> On 10/10/07, Zac Medico <zmedico@gentoo.org> wrote:
>> I think it's OK to start using package.use now considering that
>> package.use has been supported since portage-2.1.2 and that's been
>> stable since February. There are already a couple of packages using
>> it in the tree now.
> 
> Is it a good idea for those ebuilds that require new features to have
> a >= dependency on a specific version of portage ? Or not ? Can this
> help when switching EAPIs ? Or plug the gap while the decision to
> switch to EAPI=1 is being taken ? Does /me need more coffee or a good
> clue-batting session ?
> 
> Denis.

Adding a dependency on >=sys-apps/portage-2.1.2 is a reasonable idea
since that does ensure that the package.use is properly accounted
for. Since EAPI only governs ebuilds and not profiles, you'd have to
use IUSE defaults to get a similar effect while taking advantage of
EAPI. The problem with EAPI-1 at the moment is that it's only
supported by an unstable version of portage, which means that
repoman users with stable portage will be unable to work with any
ebuilds that have EAPI=1 defined.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHDJNZ/ejvha5XGaMRAv0BAJwIxec1FPMJQYjSJeolEyVC4njgfQCeMKb+
8YgKitdWk8difKGR4nJkYuo=
=51KN
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[Marius Mauch]

On Wed, 10 Oct 2007 10:16:03 +0200
"Denis Dupeyron" <calchan@gentoo.org> wrote:

> On 10/10/07, Zac Medico <zmedico@gentoo.org> wrote:
> > I think it's OK to start using package.use now considering that
> > package.use has been supported since portage-2.1.2 and that's been
> > stable since February. There are already a couple of packages using
> > it in the tree now.
> 
> Is it a good idea for those ebuilds that require new features to have
> a >= dependency on a specific version of portage ? Or not ?

No, as it wouldn't help anyway: the depgraph is calculated before
portage would be updated (so package.use/IUSE defaults wouldn't be
used).
See http://dev.gentoo.org/~genone/docs/treedeps.txt for some
information on this kind of issues (while the text wasn't written with
this issue in mind it still applies to it).

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marius Mauch wrote:
> On Wed, 10 Oct 2007 10:16:03 +0200
> "Denis Dupeyron" <calchan@gentoo.org> wrote:
> 
>> On 10/10/07, Zac Medico <zmedico@gentoo.org> wrote:
>>> I think it's OK to start using package.use now considering that
>>> package.use has been supported since portage-2.1.2 and that's been
>>> stable since February. There are already a couple of packages using
>>> it in the tree now.
>> Is it a good idea for those ebuilds that require new features to have
>> a >= dependency on a specific version of portage ? Or not ?
> 
> No, as it wouldn't help anyway: the depgraph is calculated before
> portage would be updated (so package.use/IUSE defaults wouldn't be
> used).

Results may vary if the user doesn't manually upgrade portage before
doing other upgrades. After portage upgrades itself it will exec
emerge --resume if there are remaining packages in the merge list.
Like you said, the new version of portage will not recalculate
dependencies when it resumes, but it will recalculate USE flags
(bugs #183683). It's inconsistent, which is one reason why the
recommended practice is to upgrade portage alone before attempting
to do additional updates. Eventually I'd like to add an option that
behaves similar to --resume but also recalculates dependencies.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHDQwB/ejvha5XGaMRAr2FAJ9E0OtHnzKO+fYRahsqR6W13AYzvwCggIIi
BqHtFv3zbFKoYj5bR7heK9k=
=SaBU
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[Denis Dupeyron]

On 10/10/07, Zac Medico <zmedico@gentoo.org> wrote:
> Eventually I'd like to add an option that
> behaves similar to --resume but also recalculates dependencies.

Why not make that the default ? That would be safer IMO.

Plus, once we have this, it looks to me that nobody has to wait for
EAPI=1 in order to use whatever portage feature that's needed by an
ebuild. So we can all stop complaining about not having EAPI=1 in the
form we wanted or at all, and get back to writing ebuilds.

Denis.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denis Dupeyron wrote:
> On 10/10/07, Zac Medico <zmedico@gentoo.org> wrote:
>> Eventually I'd like to add an option that
>> behaves similar to --resume but also recalculates dependencies.
> 
> Why not make that the default ? That would be safer IMO.

I agree. At a minimum, it should bail out if the previously
calculated dependencies are no longer met. The only sanity check
that it currently does it to verify that the packages are still
available to be merged.

> Plus, once we have this, it looks to me that nobody has to wait for
> EAPI=1 in order to use whatever portage feature that's needed by an
> ebuild. So we can all stop complaining about not having EAPI=1 in the
> form we wanted or at all, and get back to writing ebuilds.

For metadata syntax changes, such as IUSE defaults, a simple portage
dependency won't work. In that case EAPI is needed in order to
prevent older versions of portage from interpreting new ebuilds in
ways that are not intended (leading to unpredictable results).

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHDSiW/ejvha5XGaMRArQeAKC9T90xrAq2SurgCM1qQ/DhbgjBMwCguXzH
HLiySuH3xV7lh70dVjsF7Tk=
=pmbn
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Getting rid of lurking no* USE flags - profile-based package.use

[Steve Long]

Zac Medico wrote:

>> Plus, once we have this, it looks to me that nobody has to wait for
>> EAPI=1 in order to use whatever portage feature that's needed by an
>> ebuild. So we can all stop complaining about not having EAPI=1 in the
>> form we wanted or at all, and get back to writing ebuilds.
> 
> For metadata syntax changes, such as IUSE defaults, a simple portage
> dependency won't work. In that case EAPI is needed in order to
> prevent older versions of portage from interpreting new ebuilds in
> ways that are not intended (leading to unpredictable results).
> 
Is there a cut-off for portage atm wrt versions you do not support?

I'm wondering at what point you can say we don't support less than 2.1.2. It
seems odd that a distro which operates like Gentoo would not cut off
support for old versions in line with the rest of the tree, when binary
ones do (which is why ubuntu LTS was attractive.)


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Getting rid of lurking no* USE flags - profile-based package.use

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve Long wrote:
> Zac Medico wrote:
> 
>>> Plus, once we have this, it looks to me that nobody has to wait for
>>> EAPI=1 in order to use whatever portage feature that's needed by an
>>> ebuild. So we can all stop complaining about not having EAPI=1 in the
>>> form we wanted or at all, and get back to writing ebuilds.
>> For metadata syntax changes, such as IUSE defaults, a simple portage
>> dependency won't work. In that case EAPI is needed in order to
>> prevent older versions of portage from interpreting new ebuilds in
>> ways that are not intended (leading to unpredictable results).
>>
> Is there a cut-off for portage atm wrt versions you do not support?
> 
> I'm wondering at what point you can say we don't support less than 2.1.2. It
> seems odd that a distro which operates like Gentoo would not cut off
> support for old versions in line with the rest of the tree, when binary
> ones do (which is why ubuntu LTS was attractive.)

We don't introduce incompatible changes into the tree until the
required features have been available in the in a stable version of
portage for at least 1 year. The purpose of EAPI is to minimize the
impact of incompatible changes so that we can start using new
extensions as soon as possible. See
http://dev.gentoo.org/~genone/docs/treedeps.txt for more ideas
(Marius already mentioned this earlier in the thread).

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHDxnT/ejvha5XGaMRAuGxAJ9sRww2ryQZEuBC2Lo958Q7uOlLQwCdFI4d
MyrGAZQkb+2T4FdrTksakxM=
=s5uA
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Getting rid of lurking no* USE flags - profile-based package.use

[Steve Long]

Zac Medico wrote:
> Steve Long wrote:
>> Is there a cut-off for portage atm wrt versions you do not support?
>> 
>> I'm wondering at what point you can say we don't support less than 2.1.2.
>> It seems odd that a distro which operates like Gentoo would not cut off
>> support for old versions in line with the rest of the tree, when binary
>> ones do (which is why ubuntu LTS was attractive.)
> 
> We don't introduce incompatible changes into the tree until the
> required features have been available in the in a stable version of
> portage for at least 1 year. The purpose of EAPI is to minimize the
> impact of incompatible changes so that we can start using new
> extensions as soon as possible. See
> http://dev.gentoo.org/~genone/docs/treedeps.txt for more ideas
> (Marius already mentioned this earlier in the thread).
> 
Yeah, I looked at that before, but it went straight over my head. Looking at
it again, it seems like option A combined with a virtual/pkgmanager
(version could be EAPI since EAPI 1 features are apparently needed now)
would be the easiest and would have no cons?


-- 
gentoo-dev@gentoo.org mailing list