[gentoo-dev] Lastrites: sci-libs/blas-atlas & sci-libs/lapack-atlas

[gentoo-dev] Lastrites: sci-libs/blas-atlas & sci-libs/lapack-atlas

[justin]

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

# Justin Lecher <jlec@gentoo.org> (5 Dec 2012)
# sci-libs/(lapack/blas)-altas will be removed due to
# fragile build and runtime behaviour #372323.
# Alternatives are sci-libs/lapack-reference & sci-libs/blas-reference.
# Follow up package named sci-libs/atlas can be found in
# sci overlay and will be moved once ready for prime time
sci-libs/blas-atlas
sci-libs/lapack-atlas


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

[gentoo-dev] Cleaning tree of outdated packages

[Jory A. Pratt]

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

As many of us are aware the tree is growing to a size that is really
unacceptable for many. We have many packages that have excessive amounts
of versions laying around that are not used any more. Many of these
packages with excessive revisions most likely do not work with modern
code any longer, or have security exploits or just dead upstreams that
do not support them any longer that have been replaced with newer
packages. Well these packages are around for stable at the moment when a
newer package replaces the old and makes stable branch we need to remove
the dead package. This is nothing but an attempt to start reducing the
size of the tree and supported packages as a whole to improve the
quality of Gentoo as a WHOLE. All packages of course need to be handled
in a manner that works with maintainers/herd and the community as a whole.

Jory
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQyh8NAAoJEKDMw7q00Ii0PqgH/0u2G3arUAjMSD2UxQ2pcVtr
DNHSbltLM/Lk4DakHis+FpM4A7HtQRatg2V+EPcU6C20Co5f5IWhiEKbU84JXLxD
8+FwOLsNVkKEAqI3Se3il4cn0YvT4KdkGwwqH036CR06+J9FEPz/7iai88B4iXaS
s/KaVb8HwdG2ssykC4n+6U8Fh599x8upu9Gh9wX3iClFyTSYhK0vCFiDgg/FDK1Y
e6CHKuy8QK8gmlNqee3KarYLOTzcIClqJM7dbK6DGce3HxvtCfXDwtxOkNDNeUi0
UF33PHzzruHSN5LR6fnEwYTIPPfjKPZXzJgzdcmgR1i6T/K/8xEE1jQQ52DnDEs=
=TVWV
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Cleaning tree of outdated packages

[Pacho Ramos]

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

El jue, 13-12-2012 a las 12:31 -0600, Jory A. Pratt escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> As many of us are aware the tree is growing to a size that is really
> unacceptable for many. We have many packages that have excessive amounts
> of versions laying around that are not used any more. Many of these
> packages with excessive revisions most likely do not work with modern
> code any longer, or have security exploits or just dead upstreams that
> do not support them any longer that have been replaced with newer
> packages. Well these packages are around for stable at the moment when a
> newer package replaces the old and makes stable branch we need to remove
> the dead package. This is nothing but an attempt to start reducing the
> size of the tree and supported packages as a whole to improve the
> quality of Gentoo as a WHOLE. All packages of course need to be handled
> in a manner that works with maintainers/herd and the community as a whole.
> 
> Jory

I think Ago had a script for doing that task... but each team/herd will
need to give him permission for cleaning old versions I think ;)

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

Re: [gentoo-dev] Cleaning tree of outdated packages

[Tomáš Chvátal]

2012/12/13 Jory A. Pratt <anarchy@gentoo.org>:
>
> As many of us are aware the tree is growing to a size that is really
> unacceptable for many. We have many packages that have excessive amounts
> of versions laying around that are not used any more. Many of these
> packages with excessive revisions most likely do not work with modern
> code any longer, or have security exploits or just dead upstreams that
> do not support them any longer that have been replaced with newer
> packages. Well these packages are around for stable at the moment when a
> newer package replaces the old and makes stable branch we need to remove
> the dead package. This is nothing but an attempt to start reducing the
> size of the tree and supported packages as a whole to improve the
> quality of Gentoo as a WHOLE. All packages of course need to be handled
> in a manner that works with maintainers/herd and the community as a whole.
>
> Jory
>
>
Please press enter more often when sending mails :P So we can in-post
rather than bottom/top post to your mails.

I totaly agree that we should reduce amount of versions we provide in
main tree and I tried to adhere to this policy in all herds I am
member of or whenever I found some insane stuff in cvs.

But there is one big ass but. We have some packages that were
stabilised last time few year back and they provide multiple testing
versions on top of that.
Who is the one to deterimine which one should go stable and which to get rid of?
We had some humble tryouts to create automatic stabilisation request
which didn't turn out exactly well as most of the maintainers had to
actually do more work ;-)


Long story short for to have some sane policy wrt amounts of the
stable packages. Testing packages can't be handled easily by some rule
because the development differs everywhere.
Packages should provide only one stable version per branch/slot by default.
Exception for this rule are base-system packages where requirement is
to provide two stable versions at any given time.

Re: [gentoo-dev] Cleaning tree of outdated packages

[Tomáš Chvátal]

2012/12/13 Tomáš Chvátal <tomas.chvatal@gmail.com>:
>
> But there is one big ass but. We have some packages that were
> stabilised last time few year back and they provide multiple testing
> versions on top of that.
> Who is the one to deterimine which one should go stable and which to get rid of?
> We had some humble tryouts to create automatic stabilisation request
> which didn't turn out exactly well as most of the maintainers had to
> actually do more work ;-)
>
>
I did not ment to send this! It is mail WIP I wanted to store in draft
folder... anyway so let me expand here:

We need some metadata.xml tag that would allow automatic
stabilisations without maintainer step so we can speed up things at
some pace.
Then we need some nice page displaying results of possible
stabilisations, where members of Arch teams or AT guys would open up
new bugs where ccing the respective archs.

Apart from that I dunno what exactly ATs would strive for so Ago, or
anyone else please show up some ideas :-)

Cheers

Tom

Re: [gentoo-dev] Cleaning tree of outdated packages

[Jory A. Pratt]

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

On 12/13/2012 12:48 PM, Tomáš Chvátal wrote:
>
> But there is one big ass but. We have some packages that were
> stabilised last time few year back and they provide multiple testing
> versions on top of that.
> Who is the one to deterimine which one should go stable and which to
get rid of?
> We had some humble tryouts to create automatic stabilisation request
> which didn't turn out exactly well as most of the maintainers had to
> actually do more work ;-)
It is always up to the maintainer/herd as to when a package goes stable.
But to keep ebuilds for ex. gcc around for over 5 years is just insane.
Keep packages around that have been replaced with a newer package is
just insane. Yes the newer package has to move to stable first, but we
should be cleaning the tree up to only support what we really and truly
are gonna support. Do we really want to try and use gcc-2.95 to build
kernel-3.7? I highly doubt it would even work.
>
>
>
> Long story short for to have some sane policy wrt amounts of the
> stable packages. Testing packages can't be handled easily by some rule
> because the development differs everywhere.
> Packages should provide only one stable version per branch/slot by
default.
> Exception for this rule are base-system packages where requirement is
> to provide two stable versions at any given time.
>
>
Well there are exceptions to every rule, it is the ideal to get a
discussion to make a better decision as to when a revision of a package
should be removed and no longer supported. Well many slots can be useful
for many packages, there has to be a time we start removing them older
slots that just are not practical any longer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQyiWcAAoJEKDMw7q00Ii0yyAIAJqgILtFzx8VSm8ULXP4vEgv
eEUu6eOO30QUnTb7aR8mYfY62PFPyKSOX6+Juvwo+HlMnJlCA256qopGuwY9zXeq
h7tWf3dzbkZTNwLAiVgCeifxGvcBwyqQKcbk4NuY4S1eYAV3USkNncZ6t2FANx96
eCw9rN/ZAbj6qp8PRE8/e+dSi5tx3JW3/WUZzpdTFE0PGDm7qIPTRgLhsn89cPy1
619cwqhzG4+VQanyWnXf6FPoo6fhDWGMirXQe+5TV7M8wpXx7nS/QpiaONIxLn9W
/I+aVQXEVld1dWrw44YGhZX3kdBlnm5ceyOGm+9dXTkXxYL1OVmU5b8VAYP0sOo=
=ceAZ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Cleaning tree of outdated packages

[William Hubbs]

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

I think another good reason for treecleaning a package is if upstream for
the package stops supporting their package and recommends that you use
a new package. In this situation, once the new package hits stable,
there is really not a reason to keep the old package around. Instead,
any necessary transition to the new package should be done and the old
package should be treecleaned.

William


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

Re: [gentoo-dev] Cleaning tree of outdated packages

[Pacho Ramos]

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

El jue, 13-12-2012 a las 13:10 -0600, William Hubbs escribió:
> I think another good reason for treecleaning a package is if upstream for
> the package stops supporting their package and recommends that you use
> a new package. In this situation, once the new package hits stable,
> there is really not a reason to keep the old package around. Instead,
> any necessary transition to the new package should be done and the old
> package should be treecleaned.
> 
> William
> 

I think we already try to do that... the problem is that sometimes some
packages are forgotten :S

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

Re: [gentoo-dev] Cleaning tree of outdated packages

[Markos Chandras]

On 13 December 2012 19:28, Pacho Ramos <pacho@gentoo.org> wrote:
> El jue, 13-12-2012 a las 13:10 -0600, William Hubbs escribió:
>> I think another good reason for treecleaning a package is if upstream for
>> the package stops supporting their package and recommends that you use
>> a new package. In this situation, once the new package hits stable,
>> there is really not a reason to keep the old package around. Instead,
>> any necessary transition to the new package should be done and the old
>> package should be treecleaned.
>>
>> William
>>
>
> I think we already try to do that... the problem is that sometimes some
> packages are forgotten :S

We also have 720 packages listed as maintainer-needed[1] meaning
nobody is actually taking care of them.
And this number is pretty scary.

[1]http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Cleaning tree of outdated packages

[Mike Gilbert]

On Thu, Dec 13, 2012 at 1:59 PM, Jory A. Pratt <anarchy@gentoo.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/13/2012 12:48 PM, Tomáš Chvátal wrote:
>>
>> But there is one big ass but. We have some packages that were
>> stabilised last time few year back and they provide multiple testing
>> versions on top of that.
>> Who is the one to deterimine which one should go stable and which to
> get rid of?
>> We had some humble tryouts to create automatic stabilisation request
>> which didn't turn out exactly well as most of the maintainers had to
>> actually do more work ;-)
> It is always up to the maintainer/herd as to when a package goes stable.
> But to keep ebuilds for ex. gcc around for over 5 years is just insane.
> Keep packages around that have been replaced with a newer package is
> just insane. Yes the newer package has to move to stable first, but we
> should be cleaning the tree up to only support what we really and truly
> are gonna support. Do we really want to try and use gcc-2.95 to build
> kernel-3.7? I highly doubt it would even work.

I am sure that some people find it very handy to have old gcc ebuilds
around. It might come in handy for testing.

It doesn't matter if they can't compile the latest kernel. If someone
files a bug for that, it gets closed as invalid; no big deal.

So long as the maintainers keep them working, I see no problem with
old ebuilds in the tree.

Re: [gentoo-dev] Cleaning tree of outdated packages

[Jeff Horelick]

On 13 December 2012 17:57, Mike Gilbert <floppym@gentoo.org> wrote:
> On Thu, Dec 13, 2012 at 1:59 PM, Jory A. Pratt <anarchy@gentoo.org> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 12/13/2012 12:48 PM, Tomáš Chvátal wrote:
>>>
>>> But there is one big ass but. We have some packages that were
>>> stabilised last time few year back and they provide multiple testing
>>> versions on top of that.
>>> Who is the one to deterimine which one should go stable and which to
>> get rid of?
>>> We had some humble tryouts to create automatic stabilisation request
>>> which didn't turn out exactly well as most of the maintainers had to
>>> actually do more work ;-)
>> It is always up to the maintainer/herd as to when a package goes stable.
>> But to keep ebuilds for ex. gcc around for over 5 years is just insane.
>> Keep packages around that have been replaced with a newer package is
>> just insane. Yes the newer package has to move to stable first, but we
>> should be cleaning the tree up to only support what we really and truly
>> are gonna support. Do we really want to try and use gcc-2.95 to build
>> kernel-3.7? I highly doubt it would even work.
>
> I am sure that some people find it very handy to have old gcc ebuilds
> around. It might come in handy for testing.
>
> It doesn't matter if they can't compile the latest kernel. If someone
> files a bug for that, it gets closed as invalid; no big deal.
>
> So long as the maintainers keep them working, I see no problem with
> old ebuilds in the tree.
>

I tend to agree with this sentiment.

I keep several old audacious (for example) ebuilds around because the
current audacious upstream broke a useful feature in newer releases
and refuses to fix it, hence why i feel the need to keep audacious 2.x
ebuilds around. I'm going to also keep both audacious 3.2.x and
>=3.3.x around since >=3.3 is GTK3-only and (like me) there ma be some
GTK3 haters out there who want to stay away from it.

There are good reasons for keeping old ebuilds in the tree. It may
seem crufty if you're just looking at the tree, but they'll be a
blessing when you truly need them. Part of why I love being a Gentoo
users is that if something's broken in a release, I can almost always
install either an older or newer version and have my problems fixed in
5 minutes.

Re: [gentoo-dev] Cleaning tree of outdated packages

[William Hubbs]

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

On Thu, Dec 13, 2012 at 06:24:30PM -0500, Jeff Horelick wrote:
> On 13 December 2012 17:57, Mike Gilbert <floppym@gentoo.org> wrote:
> > On Thu, Dec 13, 2012 at 1:59 PM, Jory A. Pratt <anarchy@gentoo.org> wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 12/13/2012 12:48 PM, Tomáš Chvátal wrote:
> >>>
> >>> But there is one big ass but. We have some packages that were
> >>> stabilised last time few year back and they provide multiple testing
> >>> versions on top of that.
> >>> Who is the one to deterimine which one should go stable and which to
> >> get rid of?
> >>> We had some humble tryouts to create automatic stabilisation request
> >>> which didn't turn out exactly well as most of the maintainers had to
> >>> actually do more work ;-)
> >> It is always up to the maintainer/herd as to when a package goes stable.
> >> But to keep ebuilds for ex. gcc around for over 5 years is just insane.
> >> Keep packages around that have been replaced with a newer package is
> >> just insane. Yes the newer package has to move to stable first, but we
> >> should be cleaning the tree up to only support what we really and truly
> >> are gonna support. Do we really want to try and use gcc-2.95 to build
> >> kernel-3.7? I highly doubt it would even work.
> >
> > I am sure that some people find it very handy to have old gcc ebuilds
> > around. It might come in handy for testing.
> >
> > It doesn't matter if they can't compile the latest kernel. If someone
> > files a bug for that, it gets closed as invalid; no big deal.
> >
> > So long as the maintainers keep them working, I see no problem with
> > old ebuilds in the tree.
> >
> 
> I tend to agree with this sentiment.
> 
> I keep several old audacious (for example) ebuilds around because the
> current audacious upstream broke a useful feature in newer releases
> and refuses to fix it, hence why i feel the need to keep audacious 2.x
> ebuilds around. I'm going to also keep both audacious 3.2.x and
> >=3.3.x around since >=3.3 is GTK3-only and (like me) there ma be some
> GTK3 haters out there who want to stay away from it.
> 
> There are good reasons for keeping old ebuilds in the tree. It may
> seem crufty if you're just looking at the tree, but they'll be a
> blessing when you truly need them. Part of why I love being a Gentoo
> users is that if something's broken in a release, I can almost always
> install either an older or newer version and have my problems fixed in
> 5 minutes.

I don't think anyone is advocating killing all older ebuilds, just the
ones that do not have a good reason to be kept.

For example, glibc-2.9 and gcc-2.95. I think that if we are going to
keep things this old in the tree we need a good reason for them.

I'm wondering if packages assigned to maintainer-needed should be looked
at and removed since no one cares about them after they have sat there
for a certain amount of time?

William


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

Re: [gentoo-dev] Cleaning tree of outdated packages

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/12/12 06:24 PM, Jeff Horelick wrote:
> On 13 December 2012 17:57, Mike Gilbert <floppym@gentoo.org>
> wrote:
>> On Thu, Dec 13, 2012 at 1:59 PM, Jory A. Pratt
>> <anarchy@gentoo.org> wrote:
>>> 
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> On 12/13/2012 12:48 PM, Tomáš Chvátal wrote:
>>>> 
>>>> But there is one big ass but. We have some packages that
>>>> were stabilised last time few year back and they provide
>>>> multiple testing versions on top of that. Who is the one to
>>>> deterimine which one should go stable and which to
>>> get rid of?
>>>> We had some humble tryouts to create automatic stabilisation
>>>> request which didn't turn out exactly well as most of the
>>>> maintainers had to actually do more work ;-)
>>> It is always up to the maintainer/herd as to when a package
>>> goes stable. But to keep ebuilds for ex. gcc around for over 5
>>> years is just insane. Keep packages around that have been
>>> replaced with a newer package is just insane. Yes the newer
>>> package has to move to stable first, but we should be cleaning
>>> the tree up to only support what we really and truly are gonna
>>> support. Do we really want to try and use gcc-2.95 to build 
>>> kernel-3.7? I highly doubt it would even work.
>> 
>> I am sure that some people find it very handy to have old gcc
>> ebuilds around. It might come in handy for testing.
>> 
>> It doesn't matter if they can't compile the latest kernel. If
>> someone files a bug for that, it gets closed as invalid; no big
>> deal.
>> 
>> So long as the maintainers keep them working, I see no problem
>> with old ebuilds in the tree.
>> 
> 
> I tend to agree with this sentiment.
> 
> I keep several old audacious (for example) ebuilds around because
> the current audacious upstream broke a useful feature in newer
> releases and refuses to fix it, hence why i feel the need to keep
> audacious 2.x ebuilds around. I'm going to also keep both audacious
> 3.2.x and
>> =3.3.x around since >=3.3 is GTK3-only and (like me) there ma be
>> some
> GTK3 haters out there who want to stay away from it.
> 
> There are good reasons for keeping old ebuilds in the tree. It may 
> seem crufty if you're just looking at the tree, but they'll be a 
> blessing when you truly need them. Part of why I love being a
> Gentoo users is that if something's broken in a release, I can
> almost always install either an older or newer version and have my
> problems fixed in 5 minutes.
> 

+1 , the ability to install older versions of software or legacy
software is one of the reasons I switched to Gentoo in the first
place.  There is of course a point when these packages can no longer
be maintained, but until that happens there isn't any reason to me
that they should be removed.

When users follow standard installation methods, then by default they
will always have the latest stable (or latest ~arch) packages anyhow;
I don't see the older packages causing that many issues with our users
in the tree.

Of course if there isn't any need in keeping the old ebuilds around,
then yes they should probably be dropped within a short time of
another one going stable.  Users can always draw the old ebuilds out
of the attic*

*it would be nice, though, if the patchsets that inevitably disappear
from the distfiles mirrors could somehow be kept, though.  Not
necessarily on distfiles, but maybe in the maintainer's dev webspace?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDKlyYACgkQ2ugaI38ACPCw+gEAursOkSMKcxb9XwpTClo3LzsL
crKAtU0fmS/f7y0iotwA/1RXhp9w3JhcyXyNjoXsoI1eZMvx+NL9WTtLKMkehWO9
=e0Pt
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Cleaning tree of outdated packages

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/12/12 06:49 PM, William Hubbs wrote:
> For example, glibc-2.9 and gcc-2.95. I think that if we are going
> to keep things this old in the tree we need a good reason for
> them.

iirc, gcc-2.95 and linux-2.4 (still used for some embedded systems)
play best together.


> I'm wondering if packages assigned to maintainer-needed should be
> looked at and removed since no one cares about them after they have
> sat there for a certain amount of time?

They are, aren't they?  treecleaners has been doing a pretty good job
of that iirc.  At least, those that have had bugs filed against them
without being addressed...


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

iF4EAREIAAYFAlDKl7oACgkQ2ugaI38ACPD9FQD/Sw84dF4c2cEHgoYehzufFna0
pppHdUw9zxQo5Z92FvAA/1di1VUJnoF7K8fviqi+y5MBwHTCN27lfaYguc8ukQf9
=yjYK
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Cleaning tree of outdated packages

[Rich Freeman]

On Thu, Dec 13, 2012 at 10:04 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> +1 , the ability to install older versions of software or legacy
> software is one of the reasons I switched to Gentoo in the first
> place.  There is of course a point when these packages can no longer
> be maintained, but until that happens there isn't any reason to me
> that they should be removed.

Agreed.  The question isn't "should they be maintained?"  The question
is "are they being maintained?"  Gentoo is about choice, and there is
no such thing as a bad choice if the default is reasonable and
somebody cares to provide the choice in the first place.

If a package version is being maintained, then keep it.  If nobody
wants to maintain it, and it doesn't work right, then drop it.  That's
basically our treecleaning policy already.

If you can't think of a reason for having 14 versions of libfoo in the
tree, then just be happy that you don't have to look at them.  :)

I'd actually prefer that maintainers keep more versions around in
general.  One of my pet-peeves is when stable is a year old, while
testing has been bumped every other week in the meantime, but with no
version ever sticking around long enough to be stabilized.  Granted, I
realize that this isn't really the target of this campaign.

Rich

Re: [gentoo-dev] Cleaning tree of outdated packages

[William Hubbs]

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

On Thu, Dec 13, 2012 at 10:06:34PM -0500, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 13/12/12 06:49 PM, William Hubbs wrote:
> > For example, glibc-2.9 and gcc-2.95. I think that if we are going
> > to keep things this old in the tree we need a good reason for
> > them.
> 
> iirc, gcc-2.95 and linux-2.4 (still used for some embedded systems)
> play best together.

I'm not sure how strong this argument is because we don't have any 2.4
kernels in the tree, and I am wondering why we still have a
linux-headers-2.4.

> > I'm wondering if packages assigned to maintainer-needed should be
> > looked at and removed since no one cares about them after they have
> > sat there for a certain amount of time?
> 
> They are, aren't they?  treecleaners has been doing a pretty good job
> of that iirc.  At least, those that have had bugs filed against them
> without being addressed...

There seems to be a pretty high number of unmaintained packages in the
tree if you look at hwoarang's response to this thread, so I'm not sure
how that is going.

William


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

Re: [gentoo-dev] Cleaning tree of outdated packages

[William Hubbs]

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

On Thu, Dec 13, 2012 at 05:57:16PM -0500, Mike Gilbert wrote:
> I am sure that some people find it very handy to have old gcc ebuilds
> around. It might come in handy for testing.

Testhing what?

> It doesn't matter if they can't compile the latest kernel. If someone
> files a bug for that, it gets closed as invalid; no big deal.
 
I know that if someone filed a bug against something I maintain because
it wouldn't compile with this version of gcc, I would probably do the
same thing. I would close it invalid or wontfix and advise the user to
upgrade their compiler.

Gcc is just an example, but I'm saying that I agree with anarchy here.

There are actually several issues in this thread.

1. How long should old stable versions of packages be kept once a new
version is stabilized?

This depends on the package really, and the maintainer will know the
package best, but if old versions of a package have been around a very
long time maybe we should ping the maintainers with a bug and find out
why they are still in the tree.

2. What about packages that have been assigned to maintainer-needed for
a while?

At some point I think these should be removed unless someone steps up
and maintains them.

3. What about packages where it can be shown that upstream is no longer
developing the package and upstream recommends  using a new package?

I think in this case the package that was replaced should be
removed once the new package is stable and any transition work has been
done with the rest of the tree so that it supports the new package.

William


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

Re: [gentoo-dev] Cleaning tree of outdated packages

[Mike Gilbert]

On Fri, Dec 14, 2012 at 12:07 AM, William Hubbs <williamh@gentoo.org> wrote:
> On Thu, Dec 13, 2012 at 05:57:16PM -0500, Mike Gilbert wrote:
>> I am sure that some people find it very handy to have old gcc ebuilds
>> around. It might come in handy for testing.
>
> Testhing what?
>

Maybe to see if my code works with older compilers? If you suspect
that nobody is using gcc-2.95, then ping the toolchain guys.

My point was that I don't see any reason to remove old stuff if
someone is maintaining the ebuild. If you think something should be
removed, ping the maintainer; we don't need to invent some policy or
whine about it on the mailing list.

Re: [gentoo-dev] Cleaning tree of outdated packages

[Chí-Thanh Christopher Nguyễn]

William Hubbs schrieb:
>>> For example, glibc-2.9 and gcc-2.95. I think that if we are going
>>> to keep things this old in the tree we need a good reason for
>>> them.
>>
>> iirc, gcc-2.95 and linux-2.4 (still used for some embedded systems)
>> play best together.
>
> I'm not sure how strong this argument is because we don't have any 2.4
> kernels in the tree, and I am wondering why we still have a
> linux-headers-2.4.

Those systems will likely be unable to use any vanilla kernel either,
but use specially patched kernels from the hardware vendor, for which no
Gentoo package ever existed.

> There seems to be a pretty high number of unmaintained packages in the tree if you look at hwoarang's
response to this thread, so I'm not sure how that is going.

Not all maintainer-needed packages are neglected, broken or useless.


Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] Re: Cleaning tree of outdated packages

[Duncan]

William Hubbs posted on Thu, 13 Dec 2012 21:51:33 -0600 as excerpted:

> On Thu, Dec 13, 2012 at 10:06:34PM -0500, Ian Stakenvicius wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>> 
>> On 13/12/12 06:49 PM, William Hubbs wrote:
>> > For example, glibc-2.9 and gcc-2.95. I think that if we are going to
>> > keep things this old in the tree we need a good reason for them.
>> 
>> iirc, gcc-2.95 and linux-2.4 (still used for some embedded systems)
>> play best together.
> 
> I'm not sure how strong this argument is because we don't have any 2.4
> kernels in the tree, and I am wondering why we still have a
> linux-headers-2.4.

This only relatively indirectly affects me as my focus is amd64, where 
even gcc-3 has been out of support for quite some time, but from what 
I've read, there are still people who find old gcc-2.95 good for building 
old code or for various other special projects.  And given its wide 
distribution due to Red Hat, there's probably a lot of old code that 
requires 2.95.

As such, I'd suggest keeping it in the tree as long as someone can be 
found to keep it building at all on current systems.  Once there's nobody 
and it goes horribly broken so it's of no use in any case, then yeah, 
remove it, but unless/until that becomes the case, gcc-2.95 really is a 
bit of a special case, and probably does still have a few users 
supporting their strange corner-cases.

I'm no gcc history expert, but if I'm not mistaken, 3.1 has a similarly 
wide historic distribution (next redhat version?), and it's likely 
there's a reasonable case for keeping one of each gcc minor, presumably 
the last, in the tree.  However, that still leaves several as cleanable, 
with the oldest being 3.2.2.  Or it may be that 3.2 and 3.3 can be 
removed as well, leaving 2.95.3-r10, 3.1.1-r2, and 3.4.6-r2, as the only 
pre-4.0 gccs.  4.0 might be removable too as a non-major-distribution 
early 4.x, leaving 4.1.2 as the first 4.x gcc.  Obviously there's folks 
way more equipped to make those decisions than I, however.  I'm simply 
pointing out that I know for a fact that 2.95 has some serious history 
behind it, such that there really are quite possibly people using it for 
something or other, even if it's nothing even close to their primary 
system compiler, and that gcc in general is arguably a rather special 
case, with good reasons to keep quite a few more versions of it around 
than for most packages.

It may be that linux-headers-2.4 is a similarly special case, even with 
no 2.4 kernels remaining in-tree, because if there's any single package 
people are likely to procure and build independently of gentoo, it's 
likely to be the kernel, and there's a significantly higher than zero 
chance that someone, somewhere, is still building their own 2.4 kernels 
and using the 2.4 headers, not necessarily for the gentoo build system, 
but very possibly for some embedded system or other special project they 
have going on.

glibc would of course be in the same rather limited family, where a gentoo 
build system and toolchain packages are being used to support unusual 
corner-case projects.  I'm not sure about anything else, as the build 
host's PM and support packages could be current gentoo mainline, just the 
target some weird corner-case, but again, toolchain folks would know more 
about such requirements.

-- 
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-dev] Cleaning tree of outdated packages

[George Shapovalov]

On Thursday 13 December 2012 12:59:40 Jory A. Pratt wrote:
> But to keep ebuilds for ex. gcc around for over 5 years is just insane.
What?
I would argue, that stuff like gcc and some other system packages should be 
kept forewer. One (working) version per SLOT is enough, but these should just 
stay.

George

Re: [gentoo-dev] Cleaning tree of outdated packages

[George Shapovalov]

On Thursday 13 December 2012 21:25:59 Markos Chandras wrote:
> We also have 720 packages listed as maintainer-needed[1] meaning
> nobody is actually taking care of them.
> And this number is pretty scary.
Scary how?
With over 15000 packages total by now (in only the official tree; or even 
more, what are the last statistics anyway?) this makes for <5% of total. 
Reasonably good I'd say. Oh, they better be taken care of, sure. Just saying 
that some arbitraty number is scary and thus we have to kill stuff because of 
that is not right.

George

Re: [gentoo-dev] Cleaning tree of outdated packages

[Markos Chandras]

On 14 December 2012 06:21, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> William Hubbs schrieb:
>>>> For example, glibc-2.9 and gcc-2.95. I think that if we are going
>>>> to keep things this old in the tree we need a good reason for
>>>> them.
>>>
>>> iirc, gcc-2.95 and linux-2.4 (still used for some embedded systems)
>>> play best together.
>>
>> I'm not sure how strong this argument is because we don't have any 2.4
>> kernels in the tree, and I am wondering why we still have a
>> linux-headers-2.4.
>
> Those systems will likely be unable to use any vanilla kernel either,
> but use specially patched kernels from the hardware vendor, for which no
> Gentoo package ever existed.
>
>> There seems to be a pretty high number of unmaintained packages in the tree if you look at hwoarang's
> response to this thread, so I'm not sure how that is going.
>
> Not all maintainer-needed packages are neglected, broken or useless.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>
>

They may not be broken or useless but if they are not neglected,
please add yourself to metadata.xml. What's the point of having them
marked as "unmaintained" if there is a maintainer behind them?

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Cleaning tree of outdated packages

[Markos Chandras]

On 14 December 2012 07:56, George Shapovalov <george@gentoo.org> wrote:
> On Thursday 13 December 2012 21:25:59 Markos Chandras wrote:
>> We also have 720 packages listed as maintainer-needed[1] meaning
>> nobody is actually taking care of them.
>> And this number is pretty scary.
> Scary how?
> With over 15000 packages total by now (in only the official tree; or even
> more, what are the last statistics anyway?) this makes for <5% of total.
> Reasonably good I'd say. Oh, they better be taken care of, sure. Just saying
> that some arbitraty number is scary and thus we have to kill stuff because of
> that is not right.
>
> George
>

I never said to remove them. Just pointing out that the number ( as an
absolute number ) is high.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Cleaning tree of outdated packages

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/12/12 10:51 PM, William Hubbs wrote:
> On Thu, Dec 13, 2012 at 10:06:34PM -0500, Ian Stakenvicius wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> On 13/12/12 06:49 PM, William Hubbs wrote:
>>> For example, glibc-2.9 and gcc-2.95. I think that if we are 
>>> going to keep things this old in the tree we need a good
>>> reason for them.
>> 
>> iirc, gcc-2.95 and linux-2.4 (still used for some embedded 
>> systems) play best together.
> 
> I'm not sure how strong this argument is because we don't have any 
> 2.4 kernels in the tree, and I am wondering why we still have a 
> linux-headers-2.4.

Yeah i'm not arguing to keep it, just mentioning a possible use case
for it compared to newer versions.






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

iF4EAREIAAYFAlDLICkACgkQ2ugaI38ACPAKQAD/b8NgCW4xTzHQNWD1CJvBJ90O
VfmOuwqZt6Q5PZEPidsBALduZxL/MXFJQipiXv0Ux5yb2YWyczJpxgbVC6PY8bQv
=dVew
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Cleaning tree of outdated packages

[James Cloos]

>>>>> "WH" == William Hubbs <williamh@gentoo.org> writes:

WH> For example, glibc-2.9 and gcc-2.95. I think that if we are going to
WH> keep things this old in the tree we need a good reason for them.

gcc-2.95 is still the current version for some non-mainstream dist+
architecture tuples.  The ability to test whether one's code works
on 2.95 has value.  Of course, if it will not compile on mainstream
systems, that is and entirely different story.

The older compiles also do support some targets which since have been
dropped, should one want to cross-compile for such systems one would
require the archaic compiler.

In short, as long as it doesn't require *too* much effort, old versions
of slotted packages shouldn't be dropped *only* because they are old.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Cleaning tree of outdated packages

[Jeroen Roovers]

On Thu, 13 Dec 2012 21:25:59 +0000
Markos Chandras <hwoarang@gentoo.org> wrote:

> We also have 720 packages listed as maintainer-needed[1] meaning
> nobody is actually taking care of them.
> And this number is pretty scary.

> [1]http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml

Why is the number 720 scary?  We have about 16,000 packages, so that's just 5
percent of all packages. We would be in trouble if there were significantly
more m-n packages, but then the urgency would probably drive more people to
fix/remove the packages with actual problems. All the other m-n packages can
just sit there and be useful to an unknown number of users out there.

Only 135 bugs are assigned to m-n right now. Some of the affected packages are
up for removal. which we have a team for. Most of the remaining bugs can be
fixed by anyone with commit access, which is what m-n assignment is intended
for.


     jer

Re: [gentoo-dev] Cleaning tree of outdated packages

[Pacho Ramos]

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

El jue, 13-12-2012 a las 21:51 -0600, William Hubbs escribió:
[...]
> > > I'm wondering if packages assigned to maintainer-needed should be
> > > looked at and removed since no one cares about them after they have
> > > sat there for a certain amount of time?
> > 
> > They are, aren't they?  treecleaners has been doing a pretty good job
> > of that iirc.  At least, those that have had bugs filed against them
> > without being addressed...
> 
> There seems to be a pretty high number of unmaintained packages in the
> tree if you look at hwoarang's response to this thread, so I'm not sure
> how that is going.
> 
> William
> 

Regarding maintainers-needed packages, I am in its mail alias to try to
take care of them (there are more developers in its alias doing
really nice work with them) and, since I am also in treecleaners team,
we try to remember to lastrite packages under maintainer-needed umbrella
when an important bug for them is reported and there is no way to fix
them.

Then, from maintainer-needed packages point of view, I think they are
pretty clean when talking about broken packages still living in the
tree. Regarding its old stable versions, I think I talked about this
with Ago time ago and he cleaned a bunch of old versions.

The only problem I see with amount of packages under maintainer-needed umbrella
is that... would be nice to get specific maintainer/proxy-maintainers for
them or more people joining to maintainer-needed mail alias to fix
their bugs when have enough time ;)




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

Re: [gentoo-dev] Cleaning tree of outdated packages

[Mike Frysinger]

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

On Friday 14 December 2012 02:49:08 George Shapovalov wrote:
> On Thursday 13 December 2012 12:59:40 Jory A. Pratt wrote:
> > But to keep ebuilds for ex. gcc around for over 5 years is just insane.
> 
> I would argue, that stuff like gcc and some other system packages should be
> kept forewer. One (working) version per SLOT is enough, but these should
> just stay.

i do keep them forever.  just for the old stuff, i move them to the toolchain 
overlay.
-mike

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

Re: [gentoo-dev] Cleaning tree of outdated packages

[Mike Frysinger]

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

On Thursday 13 December 2012 13:59:40 Jory A. Pratt wrote:
> Well there are exceptions to every rule, it is the ideal to get a
> discussion to make a better decision as to when a revision of a package
> should be removed and no longer supported. Well many slots can be useful
> for many packages, there has to be a time we start removing them older
> slots that just are not practical any longer.

seeing as how the gcc ebuilds are maintained by the toolchain group which is 
entirely active, i frankly don't care what people think should happen to them.  
don't take this personally because it isn't -- i'll say the same thing to 
anyone who says drop the older gcc ebuilds yet isn't maintaining them.  i'll 
probably listen a bit more to a toolchain member, but since that number is low 
and they haven't been complaining ...

the expectation with the older slots is that they'll get updates on a per-case 
basis.  generally, if the fix exists and the backport isn't crazy, i'll do it.  
considering the steady influx of requests, i'm pretty sure that these do serve 
a useful purpose to people.

no one is suggesting that people have to support packages with older gcc 
versions (or if they are, then tell them to not be dumb).  we already close 
bugs filed related to gcc versions older than current stable as "upgrade to 
stable".  if a maintainer decides they want to add a particular change, then 
that's their call.

don't like the older versions ?  don't install them.  problem solved.  they 
aren't causing issues otherwise.
-mike

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

Re: [gentoo-dev] Cleaning tree of outdated packages

[Mike Frysinger]

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

On Wednesday 19 December 2012 18:56:10 Mike Frysinger wrote:
> On Friday 14 December 2012 02:49:08 George Shapovalov wrote:
> > On Thursday 13 December 2012 12:59:40 Jory A. Pratt wrote:
> > > But to keep ebuilds for ex. gcc around for over 5 years is just insane.
> > 
> > I would argue, that stuff like gcc and some other system packages should
> > be kept forewer. One (working) version per SLOT is enough, but these
> > should just stay.
> 
> i do keep them forever.  just for the old stuff, i move them to the
> toolchain overlay.

to clarify further, if i'm not keeping it in the main tree (and i do keep a 
lot there), then you can find it in the overlay
-mike

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