[gentoo-dev] The KDE overlay moves forward

[gentoo-dev] The KDE overlay moves forward

[Wulf C. Krueger]

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

Hello, fellow devs!

As you might know, the Gentoo KDE project provides an overlay with KDE4 
live ebuilds ("kde" in layman) and some of their dependencies.

For quite some time now, our progress has been impaired by the absence of 
features like USE dependencies, ranged dependencies and suggested 
dependencies.

Most of us who are working on the overlay have been using alternative 
package managers (PM) for quite some time now. Thus, the idea arose to go 
a step further and actually make good use of the capabilities they offer 
us. 

In the end, we chose to use Paludis and discussed the possibilities of a 
new, stable EAPI for our overlay with Ciaran McCreesh who kindly agreed 
to help us with that. (Thank you, Ciaran!)

Ciaran will submit a patch for PMS that enables the ability to 
*optionally* build it with kdebuild-1 documented. Thus, we will support 
any package manager that implements this EAPI.

This new EAPI, "kdebuild-1", consists of the following features (in 
addition to EAPI 1):

- "-scm" support (GLEP 54)
- new .kdebuild-1 suffix (basically GLEP 55)
- USE dependencies, including some special operators
- ranged dependencies
- :* and := slot dependencies
- src_uri arrows
- src_test is now mandatory (unless RESTRICT'ed)
- no implicit mkdir for doins
- no dohtml, dohard and dosed. 
- no old-style virtuals (i. e. no "PROVIDE")
- pkg_info on not installed packages
- src_uri labels
- PDEPEND "suggested:" label

You'll find all the details in the following local copy of PMS with the 
kdebuild-1 patch applied: http://www.mailstation.de/pms.pdf

For starters, we'll be using the new EAPI for live ebuilds (${PV}=-scm) 
only, so that users of other PMs will be able to use the rest of the 
overlay as before. That's exactly what the kdebuild-1 EAPI was designed 
to allow for.

For users of the KDE overlay's live ebuilds the new EAPI currently means 
they will have to use Paludis but there are rumours ;) other PMs are 
interested as well. That's the main reason to optionally include it in 
PMS.

For those of us working on the overlay this means we will be able to use 
exciting new features and hopefully make our lives easier.

For Gentoo as a whole this means there's plenty of opportunity to try new 
stuff and learn from the experiences.

-- 
Best regards, Wulf
(Gentoo KDE Project lead)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: The KDE overlay moves forward

[Steve Long]

Wulf C. Krueger wrote:

> For quite some time now, our progress has been impaired by the absence of
> features like USE dependencies, ranged dependencies and suggested
> dependencies.
>
How do suggested dependencies help in your work?

> Most of us who are working on the overlay have been using alternative
> package managers (PM) for quite some time now. Thus, the idea arose to go
> a step further and actually make good use of the capabilities they offer
> us.
>
Makes sense; after all you can do whatever you want in an overlay without
concern for how it will affect anyone else.
 
> You'll find all the details in the following local copy of PMS with the
> kdebuild-1 patch applied: http://www.mailstation.de/pms.pdf
> 
Thanks, I'll have a closer look when I get some downtime.

> For starters, we'll be using the new EAPI for live ebuilds (${PV}=-scm)
> only, so that users of other PMs will be able to use the rest of the
> overlay as before. That's exactly what the kdebuild-1 EAPI was designed
> to allow for.
> 
> For users of the KDE overlay's live ebuilds the new EAPI currently means
> they will have to use Paludis but there are rumours ;) other PMs are
> interested as well. That's the main reason to optionally include it in
> PMS.
> 
Could you explain exactly what -scm-foo offers over the existing -cvs
implementation? I'm assuming it's something more than what you've outlined
here.

A bit more info on how the other features have helped would be nice (maybe a
GMN article?)

Thanks.


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

Re: [gentoo-dev] Re: The KDE overlay moves forward

[Ciaran McCreesh]

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

On Tue, 18 Mar 2008 08:11:43 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > You'll find all the details in the following local copy of PMS with
> > the kdebuild-1 patch applied: http://www.mailstation.de/pms.pdf
> > 
> Thanks, I'll have a closer look when I get some downtime.

Note that there're a couple of outright lies in that draft... (Most
obviously, it's entirely wrong about the magic mkdir stuff...) Unless
anyone screams too loudly, I'll be merging an updated patch into
official PMS in the not too distant future.

> Could you explain exactly what -scm-foo offers over the existing -cvs
> implementation? I'm assuming it's something more than what you've
> outlined here.

Usable version ordering, if you mean compared to Portage's old cvs
version hack, or usable dependencies in general, if you mean compared
to foo and foo-cvs packages.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The KDE overlay moves forward

[Fabio Erculiani]

On 3/17/08, Wulf C. Krueger <philantrop@gentoo.org> wrote:
>  - USE dependencies, including some special operators
>  - ranged dependencies
>  - :* and := slot dependencies
>  - PDEPEND "suggested:" label

Nice, is there any example in the kde overlay?
I'm interested in implementing the points above but I couldn't find
any relevant example to make sure I understood all properly.

Example:
x11-libs/qt:*

In that case, what Paludis will pull? x11-libs/qt:3 or x11-libs/qt:4 ?
Is my understanding right?
Also, could you make an example for the ":= slot dependency" syntax?

>
>  --
>  Best regards, Wulf
>  (Gentoo KDE Project lead)
>
>

Thanks in advance


-- 
Fabio Erculiani
Information and Communication Technologies Consultant
Sabayon Linux Chief Architect
http://www.sabayonlinux.org
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] The KDE overlay moves forward

[Ciaran McCreesh]

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

On Tue, 18 Mar 2008 10:21:49 +0100
"Fabio Erculiani" <lxnay@sabayonlinux.org> wrote:
> Example:
> x11-libs/qt:*
> 
> In that case, what Paludis will pull? x11-libs/qt:3 or x11-libs/qt:4 ?
> Is my understanding right?
> Also, could you make an example for the ":= slot dependency" syntax?

See the section "Slot Dependencies" in chapter 9 of
http://www.mailstation.de/pms.pdf .

In non technical terms:

:* means, effectively, that the slot isn't locked at compile time, and
that if you build a package against foo:2, it will work at runtime
with foo:1 or foo:3 instead. Examples of this are many things that don't
do C-style linking.

:= means, effectively, that the slot is locked at compile time. An
example of this is a package that can use any version of 'db' -- the
package can often compile against any version of db, but if you remove
the slot of the db version against which the package was built, the
package will break.

It's used by Paludis as a hint to --uninstall and --uninstall-unused.
For normal dependencies, Paludis takes the safe option and assumes that
if something has a run dep upon foo, all installed slots of foo are
used. Using :* dependencies relaxes that restriction to any slot.
Using := dependencies changes that restriction to one specific slot.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The KDE overlay moves forward

[Fabio Erculiani]

On 3/18/08, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> On Tue, 18 Mar 2008 10:21:49 +0100
>
>
> See the section "Slot Dependencies" in chapter 9 of
>  http://www.mailstation.de/pms.pdf .

Yeah I was already reading the updated parts, thanks

>
>  In non technical terms:
>
>  :* means, effectively, that the slot isn't locked at compile time, and
>  that if you build a package against foo:2, it will work at runtime
>  with foo:1 or foo:3 instead. Examples of this are many things that don't
>  do C-style linking.
>
>  := means, effectively, that the slot is locked at compile time. An
>  example of this is a package that can use any version of 'db' -- the
>  package can often compile against any version of db, but if you remove
>  the slot of the db version against which the package was built, the
>  package will break.
>
>  It's used by Paludis as a hint to --uninstall and --uninstall-unused.
>  For normal dependencies, Paludis takes the safe option and assumes that
>  if something has a run dep upon foo, all installed slots of foo are
>  used. Using :* dependencies relaxes that restriction to any slot.
>  Using := dependencies changes that restriction to one specific slot.

Ok thanks, is there any specific GLEP already? Or is it just a Paludis proposal?
I am just wondering when this stuff will hit the tree.

Thanks for the explanation

>
>  --
>
> Ciaran McCreesh
>
>


-- 
Fabio Erculiani
Information and Communication Technologies Consultant
Sabayon Linux Chief Architect
http://www.sabayonlinux.org
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: The KDE overlay moves forward

[Duncan]

"Fabio Erculiani" <lxnay@sabayonlinux.org> posted
430880c50803180400k13a65173g582d9bd608f071cb@mail.gmail.com, excerpted
below, on  Tue, 18 Mar 2008 12:00:40 +0100:

> Ok thanks, is there any specific GLEP already? Or is it just a Paludis
> proposal? I am just wondering when this stuff will hit the tree.

Portage was and remains the "official" PM (there's some serious political 
history there if you wish to check the list archives), so until it 
supports the EAPI (including the two GLEP elements that haven't yet been 
officially adopted and are still in development in terms of council 
approval), such ebuilds are very unlikely to be allowed in the official 
tree.

The announcement took some pains to make it quite clear those ebuilds 
weren't headed for the tree anything like soon, but not being a regular 
here, you probably missed the subtext.  They were quite specific that it 
was ONLY for the live SVN ebuilds, which are severely discouraged in the 
tree anyway for QA reasons (snapshots under certain conditions, live 
ebuilds are usually overlay material only), NOT for ultimate stable 
candidates, which is by practical trend what the tree is more and more 
considered to be for as the experimental stuff heads for the overlays.

-- 
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

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

Re: [gentoo-dev] The KDE overlay moves forward

[Ciaran McCreesh]

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

On Tue, 18 Mar 2008 12:00:40 +0100
"Fabio Erculiani" <lxnay@sabayonlinux.org> wrote:
> Ok thanks, is there any specific GLEP already? Or is it just a
> Paludis proposal?

It's something done by the Gentoo KDE people, rather than Paludis
(although admittedly :*/:= was designed largely by me). You'll be able
to get formal specifications from PMS (possibly by tweaking a build
option, if we decide that kdebuild shouldn't be in the spec submitted
to the Council) in the not too distant future, but given Zac's comments
about Portage and use dependencies, it won't show up in the main tree
for as long as Portage support is considered essential.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The KDE overlay moves forward

[Wulf C. Krueger]

[-- Attachment #1: Type: Text/Plain, Size: 3437 bytes --]

Hello!

> As you might know, the Gentoo KDE project provides an overlay with KDE4
> live ebuilds ("kde" in layman) and some of their dependencies.
 
It's been about 1,5 years ago when I announced the availability of the re-
designed KDE overlay which has since been our playground/testing ground for 
new EAPI features.

Even though I'm not a Gentoo developer anymore I thought I'd let you know 
about our experiences and do a little summary:

- "-scm" support (GLEP 54)
- new .kdebuild-1 suffix (basically GLEP 55)

These two have been very useful for us. Especially the clarity of -scm as the 
version specification for live ebuilds in contrast to -9999, -9999999 or other 
variations like those.

- USE dependencies, including some special operators
- :* and := slot dependencies
- src_uri arrows
- no dohtml, dohard and dosed. 
- no old-style virtuals (i. e. no "PROVIDE")

I'm glad to see most of these features having been introduced with EAPIs 2/3. 
They've made specifying deps way clearer and more concise for us in the KDE 
overlay and improved the user experience as they allow more things to be 
handled up front.
src_uri arrows have been useful in many cases; especially when upstream 
archive names were, let's say, interesting. ;-)

- src_test is now mandatory (unless RESTRICT'ed)

I've never understood all the quarrelling about this feature. Upstream KDE is 
notoriously neglecting the test suites and still, our users and ourselves 
haven't suffered at all from making src_test mandatory with the kdebuild-1 
EAPI. Which is not really surprising considering that we test our packages, 
catch test failures and simply fix or restrict them. No harm done.

- PDEPEND "suggested:" label

The "suggested" label made it easier for our users to decide if they wanted to 
install additional packages in order to enable certain optional functionality 
which is, as we all know, abundant in KDE. With a descriptive label for each 
suggested dependency, making the right decision becomes easy.

> For those of us working on the overlay this means we will be able to use
> exciting new features and hopefully make our lives easier.

This prediction turned out to be true. It has been a fun ride and it has given 
Gentoo three new developers as well - one of which is even still among your 
ranks. ;-)
 
> For Gentoo as a whole this means there's plenty of opportunity to try new
> stuff and learn from the experiences.

Judging by what went into the Gentoo EAPIs meanwhile, I think we helped Gentoo 
make some progress as well. :-)

But, alas, times are changing and, as we've moved forward when we created the 
overlay, we've been working on Exherbo in the meantime. All of the Gentoo KDE 
overlays features were implemented in Exherbo's exheres-0 EAPI and extended, 
building upon our experiences.

Yesterday, Ingmar whom some of you will certainly remember, committed -scm 
exheres to Exherbo's KDE repository. This was the next logical "evolutionary" 
;-) step and many of our users have already migrated to Exherbo or are about 
to make the switch anyway. Others have migrated to the live ebuilds created by 
the current Gentoo KDE team.

Thus, the Gentoo KDE overlay is now obsolete and all further development will 
be continued in Exherbo. I'm going to shutdown the overlay and its resources 
on October, 31st 2009.

Best regards, Wulf C. Krüger

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]