[gentoo-dev] package graveyard

[gentoo-dev] package graveyard

[Thomas Kahle]

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

Hi,

I'm forking from a thread on gentoo-project:

On 17:26 Wed 17 Aug 2011, Markos Chandras wrote:
> Personally, I want to shrink portage. There is no way for 250 listed
> developers ( I would be glad if 100 of us were really active ) to
> maintain thousands of ebuilds. 
[...] 
> We need to support only the packages that we can *really* support and
> lets hope that more people will join in when they see their packages
> going away.

I like the idea of shrinking portage, but here's a scenario I'd like to
avoid:

1) package A is unmainted, but has a sophistacted ebuild that evolved
 over some time.

2) A has an open bug that nobody cares to fix, treecleaners come around
and remove A.

3) New dev X joines Gentoo and cares for A and startes to rewrite the
ebuild from scratch.

Is there a way for X to easily query the portage history and dig up the
ebuild that was there at some point.  She could then use the old ebuild
for their new version, but without efficient search she would probably
start from scratch.  Some packages are treecleaned in the state 'working
but with a single bug (and nobody cares)', it would be good if that
state is somehow retained after the removal.  Then you can get a fully
working package while fixing only one bug.

Searching through mailing list archives with automatted removal mails
would be my hack, what would be yours?

Cheers,
Thomas


-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/

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

Re: [gentoo-dev] package graveyard

[Alex Alexander]

On Wed, Aug 17, 2011 at 19:45, Thomas Kahle <tomka@gentoo.org> wrote:
> Hi,
>
> I'm forking from a thread on gentoo-project:
>
> On 17:26 Wed 17 Aug 2011, Markos Chandras wrote:
>> Personally, I want to shrink portage. There is no way for 250 listed
>> developers ( I would be glad if 100 of us were really active ) to
>> maintain thousands of ebuilds.
> [...]
>> We need to support only the packages that we can *really* support and
>> lets hope that more people will join in when they see their packages
>> going away.
>
> I like the idea of shrinking portage, but here's a scenario I'd like to
> avoid:
>
> 1) package A is unmainted, but has a sophistacted ebuild that evolved
>  over some time.
>
> 2) A has an open bug that nobody cares to fix, treecleaners come around
> and remove A.
>
> 3) New dev X joines Gentoo and cares for A and startes to rewrite the
> ebuild from scratch.
>
> Is there a way for X to easily query the portage history and dig up the
> ebuild that was there at some point.  She could then use the old ebuild
> for their new version, but without efficient search she would probably
> start from scratch.  Some packages are treecleaned in the state 'working
> but with a single bug (and nobody cares)', it would be good if that
> state is somehow retained after the removal.  Then you can get a fully
> working package while fixing only one bug.
>
> Searching through mailing list archives with automatted removal mails
> would be my hack, what would be yours?
>
> Cheers,
> Thomas

We could try removing all keywords and masking ebuilds that are
abandoned with bugs but upstream is still active, instead of removing
them completely. That way the ebuild will be there when/if someone
else decides to take care of the package and it will even show in
tools like eix.

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

Re: [gentoo-dev] package graveyard

[Mario Fetka]

how about adding a new tag metadata,xml so that it is not imported
into the rsync tree

Mario

2011/8/17 Alex Alexander <wired@gentoo.org>:
> On Wed, Aug 17, 2011 at 19:45, Thomas Kahle <tomka@gentoo.org> wrote:
>> Hi,
>>
>> I'm forking from a thread on gentoo-project:
>>
>> On 17:26 Wed 17 Aug 2011, Markos Chandras wrote:
>>> Personally, I want to shrink portage. There is no way for 250 listed
>>> developers ( I would be glad if 100 of us were really active ) to
>>> maintain thousands of ebuilds.
>> [...]
>>> We need to support only the packages that we can *really* support and
>>> lets hope that more people will join in when they see their packages
>>> going away.
>>
>> I like the idea of shrinking portage, but here's a scenario I'd like to
>> avoid:
>>
>> 1) package A is unmainted, but has a sophistacted ebuild that evolved
>>  over some time.
>>
>> 2) A has an open bug that nobody cares to fix, treecleaners come around
>> and remove A.
>>
>> 3) New dev X joines Gentoo and cares for A and startes to rewrite the
>> ebuild from scratch.
>>
>> Is there a way for X to easily query the portage history and dig up the
>> ebuild that was there at some point.  She could then use the old ebuild
>> for their new version, but without efficient search she would probably
>> start from scratch.  Some packages are treecleaned in the state 'working
>> but with a single bug (and nobody cares)', it would be good if that
>> state is somehow retained after the removal.  Then you can get a fully
>> working package while fixing only one bug.
>>
>> Searching through mailing list archives with automatted removal mails
>> would be my hack, what would be yours?
>>
>> Cheers,
>> Thomas
>
> We could try removing all keywords and masking ebuilds that are
> abandoned with bugs but upstream is still active, instead of removing
> them completely. That way the ebuild will be there when/if someone
> else decides to take care of the package and it will even show in
> tools like eix.
>
> --
> Alex Alexander | wired
> + Gentoo Linux Developer
> ++ www.linuxized.com
>
>

Re: [gentoo-dev] package graveyard

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 17/08/2011 06:04 ??, Mario Fetka wrote:
> how about adding a new tag metadata,xml so that it is not imported 
> into the rsync tree
> 
What is the difference between your proposal and removing the package?
In both cases, the broken ebuild does not get propagated to users.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOS/bcAAoJEPqDWhW0r/LCKGEP/AnDf0J9DVaRKfS6vpciexHx
QY8HEKnwQs5wUHnjxWvwl4135NwA5mZ2jJw6upgddDjbZaBh9a5L9yZOIS5VE9k1
2vCu+rTBdugqp5oHpFDtNpdW0QwMI1vcUJCUQR51jtZNqR/0CrBtaWtAvL4lhN+1
cyYsTQyRR5zyaA19WZlzXYZybv6m9N7tZYxEXf/usFBy/T8x21aH2igt5OFld1ts
XVxV25QKhC2D2sNMbHJ/YJvyd8f/AQBidekCOR8PcgbJPTiS8HDvGgMO9QP2CFX3
ksFsEFSA9W8HXdDtaYY2SN7bbAYyCK0zP2x6e693ndAiCvwM3UqRWkBR9DCIfkYm
o5h9uY7kgCbH0wQc/5/fpf8buPS3UHIcmlopQoqMn9qhIEL36O/QN5JX4NEFt9JQ
s4sJf/zS6lLbDv2hZB/Efdo2L33CCIlF28BukL+WyfR2OBtDdIQdxvQmhLXkFTkv
v8AYufyTtKZ4NRMzFXlXdJ3t0PdUNyX7P5+g2V5VBPaz3TtsFC8u9K1byK5ApTH8
9PBBHTs4NjriMS1JQFQWIZIG1TpxcSJAk6Xda+O64RSUfs7ajfGK7JyiPNAJPSWr
EIEtv7Rc40pDjjbAybRkN7onbOq107XTA+rWsXCMI4oOMcNZBzv81OUVk6L3qt9h
dsBPgWmweXQ+DktfDo8P
=vwO5
-----END PGP SIGNATURE-----

Re: [gentoo-dev] package graveyard

[Cyprien Nicolas]

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

Thomas Kahle wrote:
> Is there a way for X to easily query the portage history and dig up
> the ebuild that was there at some point.  She could then use the old
> ebuild for their new version, but without efficient search she would
> probably start from scratch.  Some packages are treecleaned in the
> state 'working but with a single bug (and nobody cares)', it would be
> good if that state is somehow retained after the removal.  Then you
> can get a fully working package while fixing only one bug.
> 
> Searching through mailing list archives with automatted removal
> mails would be my hack, what would be yours?

I had to do this some months ago, I wanted to try a old package
requiring some gnome-1 libs.

As you said that this kind of package are likely to have/had bugs, then
a quick search in the bugzilla should retrieve the category. After that,
sources.g.o can help finding those old ebuilds.

In my case, it was media-libs/gdk-pixbuf:0. That package was removed
with gnome-1 (and later re-added as x11-libs/gdk-pixbuf:2). Knowing
media-libs, I found it using viewvc on gentoo-x86 [1], then "show X dead
files" displays all necessary files and patches.

,Cyprien
gentoo-lisp contributor

[1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5L+V8ACgkQWxOlHn1uWpdHZACdGelU21ZvHJ8OcY77S0OMinyW
QVoAoIlDo7a4GHiY4omW2fVWUsFCrr/P
=BlFS
-----END PGP SIGNATURE-----

Re: [gentoo-dev] package graveyard

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 17/08/2011 05:56 ??, Alex Alexander wrote:
> We could try removing all keywords and masking ebuilds that are 
> abandoned with bugs but upstream is still active, instead of
> removing them completely. That way the ebuild will be there when/if
> someone else decides to take care of the package and it will even
> show in tools like eix.
> 
What about the open bugs? And why do you want to keep them around
instead of tree-cleaning them? cvs history or sources.gentoo.org contain
all of their history.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOS/pcAAoJEPqDWhW0r/LC7OEQAJOL4dZ6wITLvI9oCRhHf5th
dkEZ7+SEHuk339xNoEki7GMn84Hf9dlL1EuH2bdCLATR90KRcXkPEGaNg4F/7QvD
F5ICETCUbr8q5zR9zYv3sABX4jxmuWW34UPGsyGQkKaVj6tk8ffpDAyUaVTn6zL3
hpMBRYQfda5caGNMEO7I7Mg+xDmG2mOfDitz8ttxLgWLMJE9D4+3IEoVKq7FxFg+
u+N9y2j8cNQ3QRFzsNoNcKVYdHo/4kvsqLCAmF/scrSL+1SMn3nJRjaapxlzz4+J
pSDFAv4BPed2forW1g5GtlJA3XKF5Uh5BMAip0DdM+doTcNOVNg9AKPS3i1VhhE4
wU9oZSt01wTtHAllhNfxmnZmG03mNFvA/NOHsPZOHbndM+6Nosw2hinJCpQeNPEz
QhO+cGIj7RbydaX5VhgEM0QtMbetjoHKTn6KCruMrXcW1IXcDP999AdG3ueakXJ9
Obu/HBCj/sXy/5VKymbmaVpM4M+gs9F5MMUVdB8yS9cGa20y4dDt4iF9YWooWRLq
yaEDnNEQSy8nfGH3+TOGykgYD81rCJGtvTVDv5HIxB951dFTQZ48/lroATgxTFXB
BBFuQ+7GyYrCDoBwt7yy20UGtwbbt/WgQkwtiTNT5IxgPZKATDuD75XF8S/+PAJA
2VvlUz+NUDl5WvSG4qX/
=72YL
-----END PGP SIGNATURE-----

Re: [gentoo-dev] package graveyard

[Mario Fetka]

most users just hunt the program name and gentoo to a searchengine
they get the info that the ebuild is in cvs but in graveyard.

but hey i am just a user.

Mario

2011/8/17 Markos Chandras <hwoarang@gentoo.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 17/08/2011 06:04 ??, Mario Fetka wrote:
>> how about adding a new tag metadata,xml so that it is not imported
>> into the rsync tree
>>
> What is the difference between your proposal and removing the package?
> In both cases, the broken ebuild does not get propagated to users.
>
> - --
> Regards,
> Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
>
> iQIcBAEBCgAGBQJOS/bcAAoJEPqDWhW0r/LCKGEP/AnDf0J9DVaRKfS6vpciexHx
> QY8HEKnwQs5wUHnjxWvwl4135NwA5mZ2jJw6upgddDjbZaBh9a5L9yZOIS5VE9k1
> 2vCu+rTBdugqp5oHpFDtNpdW0QwMI1vcUJCUQR51jtZNqR/0CrBtaWtAvL4lhN+1
> cyYsTQyRR5zyaA19WZlzXYZybv6m9N7tZYxEXf/usFBy/T8x21aH2igt5OFld1ts
> XVxV25QKhC2D2sNMbHJ/YJvyd8f/AQBidekCOR8PcgbJPTiS8HDvGgMO9QP2CFX3
> ksFsEFSA9W8HXdDtaYY2SN7bbAYyCK0zP2x6e693ndAiCvwM3UqRWkBR9DCIfkYm
> o5h9uY7kgCbH0wQc/5/fpf8buPS3UHIcmlopQoqMn9qhIEL36O/QN5JX4NEFt9JQ
> s4sJf/zS6lLbDv2hZB/Efdo2L33CCIlF28BukL+WyfR2OBtDdIQdxvQmhLXkFTkv
> v8AYufyTtKZ4NRMzFXlXdJ3t0PdUNyX7P5+g2V5VBPaz3TtsFC8u9K1byK5ApTH8
> 9PBBHTs4NjriMS1JQFQWIZIG1TpxcSJAk6Xda+O64RSUfs7ajfGK7JyiPNAJPSWr
> EIEtv7Rc40pDjjbAybRkN7onbOq107XTA+rWsXCMI4oOMcNZBzv81OUVk6L3qt9h
> dsBPgWmweXQ+DktfDo8P
> =vwO5
> -----END PGP SIGNATURE-----
>
>

Re: [gentoo-dev] package graveyard

[Florian Philipp]

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

Am 17.08.2011 18:45, schrieb Thomas Kahle:
> Hi,
> 
> I'm forking from a thread on gentoo-project:
> 
> On 17:26 Wed 17 Aug 2011, Markos Chandras wrote:
>> Personally, I want to shrink portage. There is no way for 250 listed
>> developers ( I would be glad if 100 of us were really active ) to
>> maintain thousands of ebuilds. 
>
[...]
> 
> Is there a way for X to easily query the portage history and dig up the
> ebuild that was there at some point.  She could then use the old ebuild
> for their new version, but without efficient search she would probably
> start from scratch.  Some packages are treecleaned in the state 'working
> but with a single bug (and nobody cares)', it would be good if that
> state is somehow retained after the removal.  Then you can get a fully
> working package while fixing only one bug.
> 
> Searching through mailing list archives with automatted removal mails
> would be my hack, what would be yours?
> 
> Cheers,
> Thomas
> 
> 

There is already an easy way to query portage's history: CVS.

# Check out working copy if you don't have it
cvs -d :pserver:anonymous@anoncvs.gentoo.org/var/cvsroot co gentoo-x86

# Show all files that ever were under version control
# You definitely want to store the output because it takes some time
cvs -q -d :pserver:anonymous@anoncvs.gentoo.org/var/cvsroot log -NSR > \
 logfile

# Grep for files in Attic, aka removed files
grep /Attic/ logfile

Finding the last revision and restoring it can be done similarly.

Hope this helps,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] package graveyard

[Matthew Summers]

On Wed, Aug 17, 2011 at 11:56 AM, Alex Alexander <wired@gentoo.org> wrote:
> On Wed, Aug 17, 2011 at 19:45, Thomas Kahle <tomka@gentoo.org> wrote:
>> Hi,
>>
>> I'm forking from a thread on gentoo-project:
>>
>> On 17:26 Wed 17 Aug 2011, Markos Chandras wrote:
>>> Personally, I want to shrink portage. There is no way for 250 listed
>>> developers ( I would be glad if 100 of us were really active ) to
>>> maintain thousands of ebuilds.
>> [...]
>>> We need to support only the packages that we can *really* support and
>>> lets hope that more people will join in when they see their packages
>>> going away.
>>
>> I like the idea of shrinking portage, but here's a scenario I'd like to
>> avoid:
>>
>> 1) package A is unmainted, but has a sophistacted ebuild that evolved
>>  over some time.
>>
>> 2) A has an open bug that nobody cares to fix, treecleaners come around
>> and remove A.
>>
>> 3) New dev X joines Gentoo and cares for A and startes to rewrite the
>> ebuild from scratch.
>>
>> Is there a way for X to easily query the portage history and dig up the
>> ebuild that was there at some point.  She could then use the old ebuild
>> for their new version, but without efficient search she would probably
>> start from scratch.  Some packages are treecleaned in the state 'working
>> but with a single bug (and nobody cares)', it would be good if that
>> state is somehow retained after the removal.  Then you can get a fully
>> working package while fixing only one bug.
>>
>> Searching through mailing list archives with automatted removal mails
>> would be my hack, what would be yours?
>>
>> Cheers,
>> Thomas
>
> We could try removing all keywords and masking ebuilds that are
> abandoned with bugs but upstream is still active, instead of removing
> them completely. That way the ebuild will be there when/if someone
> else decides to take care of the package and it will even show in
> tools like eix.
>
> --
> Alex Alexander | wired
> + Gentoo Linux Developer
> ++ www.linuxized.com
>
>

+1 on this. It saves the ebuild for posterity AND prevents users
hitting nasty bits. This seems to me to beg for a proper well-defined
policy, in any case.

-- 
Matthew W. Summers
Gentoo Foundation Inc.

Re: [gentoo-dev] package graveyard

[Rémi Cardona]

Le 17/08/2011 21:57, Matthew Summers a écrit :
> +1 on this. It saves the ebuild for posterity AND prevents users
> hitting nasty bits. This seems to me to beg for a proper well-defined
> policy, in any case.
> 

We already have a policy for this and it's called portage.

If a package is broken (and I mean with known ebuild issues, with known
bugs, etc), then we already have legitimate reasons to remove it.

If not, just let them be in portage.

If anything, working on tinderboxes to catch build issues early and file
bugs against packages, _that_ would help to clean up cruft from portage.

Rémi

[gentoo-dev] Tinderboxing (was Re: package graveyard)

[Diego Elio Pettenò]

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

Il giorno mer, 17/08/2011 alle 23.20 +0200, Rémi Cardona ha scritto:
> 
> If anything, working on tinderboxes to catch build issues early and
> file
> bugs against packages, _that_ would help to clean up cruft from
> portage. 

Maintainers can help that by making sure that src_test is not wasting
useless time running non-tests, false positives, or code deemed to
failure.

Also, make sure that packages do not collide/block just for the sake of
doing so. If they provide binaries with the same name and functionality,
consider making them eselectable, or rename one of them.. if they have
the same name and do different stuff, get one (or both) upstream to
understand that the name is too generic, or already taken, and rename
the file once and for all.

Thank you all,

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

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

[gentoo-dev] Re: Tinderboxing (was Re: package graveyard)

[Diego Elio Pettenò]

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

Il giorno gio, 18/08/2011 alle 12.01 +0200, Diego Elio Pettenò ha
scritto:
> 
> Thank you all,

Oh and please remember that if your package is not a kernel module, your
CONFIG_CHECK variable should have ~-tests (i.e., notify if not
configured properly but do not die in the ebuild if so).

It is epically bothersome to change a fake kernel configuration just
because a package _needs it to run_.

Dying/failing tests if the features are not available might make a bit
more sense, but even that is borderline, given that in a container
(which is what _I_ use for tinderboxing) the kernel configuration does
not correspond at all with the one the host is running, and that's the
one that is meaningful.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

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