[gentoo-portage-dev] [RFC] portage-2.1.6 release plans

[gentoo-portage-dev] [RFC] portage-2.1.6 release plans

[Zac Medico]

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

Hi everyone,

Lots of people have expressed an urgent desire to have a stable
version of portage that includes EAPI 2 support and automatic
blocker resolution for cases like bug 244511.

Since portage-2.2 isn't quite ready yet due to ongoing work in
package sets and preserve-libs, and I don't want ongoing work to
hold back other features that are stable, I'm planning to split a
2.1.6 branch from trunk. This branch will have package sets and
preserve-libs support disabled. This branch will be named 2.1.6 in
order to preserve continuity such that the final portage-2.2 release
will have all of the features that have existed in previous
portage-2.2 releases.

In order to get testing on the new 2.1.6 branch, I plan to put
portage-2.2 back in package.mask until portage-2.1.6 has been marked
stable.

Does this plan sound good? Are there any objections or suggestions?

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkU0YUACgkQ/ejvha5XGaOSfgCg7OVXmAPj48uaNpZ30NteH/DH
QzMAoNHOHklCppYWUJn5oMUR//2Xu5hp
=w6Wo
-----END PGP SIGNATURE-----

[gentoo-portage-dev] Re: [RFC] portage-2.1.6 release plans

[Duncan]

Zac Medico <zmedico@gentoo.org> posted 4914D188.4010803@gentoo.org,
excerpted below, on  Fri, 07 Nov 2008 15:38:48 -0800:

> Since portage-2.2 isn't quite ready yet due to ongoing work in package
> sets and preserve-libs, and I don't want ongoing work to hold back other
> features that are stable, I'm planning to split a 2.1.6 branch from
> trunk. This branch will have package sets and preserve-libs support
> disabled. This branch will be named 2.1.6 in order to preserve
> continuity such that the final portage-2.2 release will have all of the
> features that have existed in previous portage-2.2 releases.
> 
> In order to get testing on the new 2.1.6 branch, I plan to put
> portage-2.2 back in package.mask until portage-2.1.6 has been marked
> stable.

The idea is (or would be) good, but with kde4 being one of the biggest 
and highest profile users of the new features including sets and with it 
already ~arch, I'm not sure how practical putting 2.2 or set support back 
in package mask really is.  Do we really want to deal with the PR and 
other implications of putting kde4 back in package mask?

OTOH, maybe you've discussed it with the KDE project already and they 
said do what you need to do.  Maybe after all that work on and delay for 
sets, they've decided they can do without, for the time being?

IOW, preserve-libs I think you could get away with, but I just don't 
think it's practical to even consider killing ~arch portage with set 
support.  But I'm not a dev, and maybe it's just me. <shrug>

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-portage-dev] Re: [RFC] portage-2.1.6 release plans

[Zac Medico]

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

Duncan wrote:
> Zac Medico <zmedico@gentoo.org> posted 4914D188.4010803@gentoo.org,
> excerpted below, on  Fri, 07 Nov 2008 15:38:48 -0800:
> 
>> Since portage-2.2 isn't quite ready yet due to ongoing work in package
>> sets and preserve-libs, and I don't want ongoing work to hold back other
>> features that are stable, I'm planning to split a 2.1.6 branch from
>> trunk. This branch will have package sets and preserve-libs support
>> disabled. This branch will be named 2.1.6 in order to preserve
>> continuity such that the final portage-2.2 release will have all of the
>> features that have existed in previous portage-2.2 releases.
>>
>> In order to get testing on the new 2.1.6 branch, I plan to put
>> portage-2.2 back in package.mask until portage-2.1.6 has been marked
>> stable.
> 
> The idea is (or would be) good, but with kde4 being one of the biggest 
> and highest profile users of the new features including sets and with it 
> already ~arch, I'm not sure how practical putting 2.2 or set support back 
> in package mask really is.  Do we really want to deal with the PR and 
> other implications of putting kde4 back in package mask?
> 
> OTOH, maybe you've discussed it with the KDE project already and they 
> said do what you need to do.  Maybe after all that work on and delay for 
> sets, they've decided they can do without, for the time being?

I haven't talked to them about it but AFAIK it entirely possible to
use kde4 without package sets since the meta-ebuilds are available.

> IOW, preserve-libs I think you could get away with, but I just don't 
> think it's practical to even consider killing ~arch portage with set 
> support.  But I'm not a dev, and maybe it's just me. <shrug>

Well, package set support just isn't stable yet. We can make all of
the other features wait for it if that's what people really want to
do. <shrug>

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkU5X0ACgkQ/ejvha5XGaNNNgCg1dQDZw7ZT5iSwc7vMMDGCrfs
YtEAoMPogQMnySq4kA7I7ANe7Hvpz0uF
=0T7f
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] [RFC] portage-2.1.6 release plans

[Marius Mauch]

On Fri, 07 Nov 2008 15:38:48 -0800
Zac Medico <zmedico@gentoo.org> wrote:

> Since portage-2.2 isn't quite ready yet due to ongoing work in
> package sets and preserve-libs, and I don't want ongoing work to
> hold back other features that are stable, I'm planning to split a
> 2.1.6 branch from trunk. This branch will have package sets and
> preserve-libs support disabled.

Disabled as in FEATURES="-preserve-libs" and an almost empty
sets.conf, or disabled as in "remove all traces from the code"?

Marius

Re: [gentoo-portage-dev] [RFC] portage-2.1.6 release plans

[Zac Medico]

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

Marius Mauch wrote:
> On Fri, 07 Nov 2008 15:38:48 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> Since portage-2.2 isn't quite ready yet due to ongoing work in
>> package sets and preserve-libs, and I don't want ongoing work to
>> hold back other features that are stable, I'm planning to split a
>> 2.1.6 branch from trunk. This branch will have package sets and
>> preserve-libs support disabled.
> 
> Disabled as in FEATURES="-preserve-libs" and an almost empty
> sets.conf, or disabled as in "remove all traces from the code"?

I think the relevant APIs should be made private so that people
won't write code that relies on them, and things like sets.conf and
/var/lib/portage/world_sets should be completely disabled so that
people won't rely on them either.

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkVJ6sACgkQ/ejvha5XGaOZqQCffLU2qPkOfTNEzvXtKw7l4+v6
XVAAoL8hP/xVPk4n9D1/qkoDdktyhutO
=WI9Q
-----END PGP SIGNATURE-----

[gentoo-portage-dev] Re: [RFC] portage-2.1.6 release plans

[Duncan]

Zac Medico <zmedico@gentoo.org> posted 4914E580.5010502@gentoo.org,
excerpted below, on  Fri, 07 Nov 2008 17:04:00 -0800:

> I haven't talked to [the kde project] about [hard-masking all portage 
versions with set support] but AFAIK it entirely possible to use
> kde4 without package sets since the meta-ebuilds are available.

Hmm... I followed the kde4 guide, which talks about sets, and was under 
the impression they either weren't even doing the metapackages, with sets 
supplanting them, of if they were, they were using set dependencies, thus 
required sets.

A quick look demonstrates that impression was wrong, however.  I'd never 
even checked to see if the meta-ebuilds were actually there!

So... it seems the ebuilds are there.  Never-the-less, for folks who have 
followed the kde4 guide, sets will be (almost) a must, since that's what 
it talks about using, so that's probably what folks who read the guide 
/did/ use.  I know it's what I used.[1]

Regardless, I'd definitely touch base with them on it.  At minimum, the 
upgrade guide will need either changed or taken down, if set support goes 
back hard-masked.  I doubt they'll be very happy about it, but if it 
needs to happen, well...

[1] FWIW, I have kde-4.1.2 merged, but consider it still broken and well 
short of what I'd find actually workable for daily use.  There's just too 
many bits and pieces that don't work, and won't work until at least 
4.2.0, possibly 4.3.0 the way things are going.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-portage-dev] Re: [RFC] portage-2.1.6 release plans

[Zac Medico]

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

Duncan wrote:
> Zac Medico <zmedico@gentoo.org> posted 4914E580.5010502@gentoo.org,
> excerpted below, on  Fri, 07 Nov 2008 17:04:00 -0800:
> 
>> I haven't talked to [the kde project] about [hard-masking all portage 
> versions with set support] but AFAIK it entirely possible to use
>> kde4 without package sets since the meta-ebuilds are available.
> 
> Hmm... I followed the kde4 guide, which talks about sets, and was under 
> the impression they either weren't even doing the metapackages, with sets 
> supplanting them, of if they were, they were using set dependencies, thus 
> required sets.

There is no such thing as "set dependencies" yet. It would require a
new EAPI. I'm not sure that "set dependencies" are such a good idea,
mainly because of the way that users are allowed to subtract atoms
from sets. In practice, it's somewhat like package.provided, so a
"set dependency" wouldn't actually guarantee that all the intended
atoms from that set are installed.

> A quick look demonstrates that impression was wrong, however.  I'd never 
> even checked to see if the meta-ebuilds were actually there!
> 
> So... it seems the ebuilds are there.  Never-the-less, for folks who have 
> followed the kde4 guide, sets will be (almost) a must, since that's what 
> it talks about using, so that's probably what folks who read the guide 
> /did/ use.  I know it's what I used.[1]
> 
> Regardless, I'd definitely touch base with them on it.  At minimum, the 
> upgrade guide will need either changed or taken down, if set support goes 
> back hard-masked.  I doubt they'll be very happy about it, but if it 
> needs to happen, well...

The worst case is that they'll have to unmask portage-2.2 if they
want to use sets instead of meta-ebuilds.

> [1] FWIW, I have kde-4.1.2 merged, but consider it still broken and well 
> short of what I'd find actually workable for daily use.  There's just too 
> many bits and pieces that don't work, and won't work until at least 
> 4.2.0, possibly 4.3.0 the way things are going.

I tried kde-4.1.2, using the kde-meta ebuild, when they first put it
in the tree. I wasn't comfortable with it so I use kde-3.5.x still.

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkVzV0ACgkQ/ejvha5XGaN5mwCePYo0lp9oFECPA5+CDTK81pWO
V+MAnRFBJKDtfBp4rSOWeeZkE0/ZUidW
=Uh78
-----END PGP SIGNATURE-----