Blag

He's not dead, he's resting

Paludis kdebuild-1 Removal

kdebuild-1 was an EAPI used by the Gentoo KDE team and the Genkdesvn project for various live ebuilds in overlays. It was created following a request from the Gentoo KDE project, who needed certain features that Portage had not yet implemented. It was a documented, public standard, in the same way that EAPIs 0, 1 and 2 are.

The Gentoo Council has decided that all mention of the kdebuild-1 EAPI is to be removed from the Package Manager Specification immediately. A request that this be done only after a deprecation period to give users more time to catch up was rejected. As such, support for this EAPI, including support for uninstalling packages with that EAPI, will be removed from Paludis in version 0.44.

Users should verify that they have no kdebuild-1 packages installed. If Paludis was built with the ‘inquisitio’ use flag enabled, you can use:

$ inquisitio -K installed -k EAPI kdebuild-1

Otherwise, use:

$ paludis -q '*/*::/[.EAPI=kdebuild-1]'

and, if any such packages are installed, they must be uninstalled before Paludis is upgraded.

Advertisements

12 responses to “Paludis kdebuild-1 Removal

  1. Jason December 14, 2009 at 11:38 pm

    Do any well known repos still use kdebuild-1, or has that been phased out in favor of EAPI2?

    • Ciaran McCreesh December 14, 2009 at 11:42 pm

      It’s not actively used, but a good number of users still have kdebuild-1 things installed. A package manager must know about the EAPI of an installed package to be able to uninstall it, so this affects anyone who used to use those KDE ebuilds.

      • benjamin December 15, 2009 at 1:21 pm

        I used the genkdesvn-overlay since it’s beginnings but after it became abandoned i switched to the kde-overlay (which uses those silly -9999-version numbering-scheme). It’s not nice to force someone to switch the overlays (or modify their self-maintained ebuilds), but a) the repo is dead and b) installing software from this outdated repo would fail anyway. So the real question is: Is it justified to force someoe through the upgrade-process (which requires uninstalling everything and reinstalling kde anyways) “for their own good”?
        With this message – which should possibly reposted on the experirimental section of forums.gentoo.org – users have some warning-time (obviously depending on the targeted release-date of paludis 0.44).
        To cut a long story short: Because of the death of the only overlay I know which used this EAPI the might be only few affected users, which won’t get any updates of their software (including security fixes, reasons above), forcing users to this is a viable option.

        BTW: Is it possible to move the description of this EAPI to some “historic section” of the pms? and what about paludis optionally supporting deprecated specs, that could bypass the decision made but must be activated manually?

        BTW2: When gets portage suport for -scm-packages (or is there any reason why portage-overlays keep using -9999(999-r42).ebuild packages?

        • Ciaran McCreesh December 15, 2009 at 2:22 pm

          The message will be going out in reduced form as a news item for Paludis users soon, so it will get seen.

          By Council orders, it’s not possible to keep kdebuild-1 in PMS at all — it’s to be removed immediately, with no clean migration period (I was in favour instead of making paludis 0.44 warn if users have installed kdebuild things, and removing it in 0.46). We *could* theoretically branch for it, but it’s a lot of work, and extremely messy. And Paludis won’t support undocumented EAPIs on Gentoo, since there’s just far too much room for breakage.

          Support for -scm in Portage has been one of the biggest arguments in Gentoo over the past several years. It’s probably never going to happen.

          • benjamin December 16, 2009 at 11:40 am

            Thanks for your answer, Cirian!

            Is there s.th. like an FAQ on the whole -scm vs. -9999 discussion? Or some document describing the pros and cons?
            It’s just that using some arbitrary finite number as an indicator wether this is an scm-ebuild or not seems hilarious; I mean, what happens if I released a package “bar, latest version 9999” (for whatever reason). How can – other than pasing the ebuild and realising that there is (not) a call to some known scm-programm – a package-manager decide, that this package foo-blubb/bar-9999.ebuild is actually not a live-package? How does portage do that?

            That’s why I love paludis – I just have to fire up “paludis -ip everything –dl-reinstall-scm always” to update my system – currently only the qting-edge qt-packages aren’t catched, because I use the *4.6.9999 packages and they are obviously not treated as live-packages.

            BTW: In paludis, is there support for scm-packages of branches (with that I mean s.th. like x11-libs/qt-core-4.6.scm.ebuild or alike)?

      • Anonymous December 15, 2009 at 6:24 pm

        There is no way to determine if users have kdebuilds installed or not.
        The only thing that can be confirmed is there are some users still syncing to that overlay.

        Syncing to an overlay doesn’t mean they have anything installed from that overlay

        • Ciaran McCreesh December 15, 2009 at 8:00 pm

          Actually, it’s fairly easy to determine. You just ask Paludis.

          • Anonymous December 16, 2009 at 6:40 pm

            Stop being dense
            The initial statement was:

            “It’s not actively used, but a good number of users still have kdebuild-1 things installed.”

            The reply to which was:
            “There is no way to determine if users have kdebuilds installed or not.”

            And your reply is paludis can tell.

            There is no way paludis can tell how many people are still using kdebuilds. This is a quantity you have no way of knowing UNLESS you get all paludis user to check their system

            Thus you cannot use the statement
            “still have kdebuild-1 things installed” because you have no way to even have at a guess at the numbers, you can only state how many are still trying to sync to the non-existant overlay.

            Just like Gentoo cannot tell what every user has installed YUST how many users sync to the main rsync

            • Ciaran McCreesh December 16, 2009 at 6:51 pm

              I know that there are at least some users affected, since I asked and got several responses in the affirmative. Taking the reasonable assumption that the group that I asked are reasonably representative of the userbase as a whole, one easily reaches a good number of users.

              And yes, Paludis can tell very easily. Then we simply get a sample of users to pass on what Paludis tells them, and scale up from there.

  2. Anonymous December 16, 2009 at 7:58 am

    Why does removal of kdebuild from PMS imply that its support must be removed from Paludis immediately?

    It seems as if it’s your own choice not to keep it in Paludis for a transitional period. Or did the Gentoo council ask for its removal from Paludis too?

    • Ciaran McCreesh December 16, 2009 at 2:05 pm

      Keeping support in Paludis around without a specification, or with a specification that’s split up from the rest of what we work with, is an awful lot of effort. It’s not something we can realistically do.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s