Re: Th: dropping athlon and maybe deprecating ppc?
On Saturday 28 March 2009 16:38:24 Tomasz Pala wrote: > On Tue, Mar 10, 2009 at 08:19:44 +0100, Arkadiusz Miskiewicz wrote: > > Could some athlon*rpm owner see if upgrading athlon->i686 is nicely > > handled in poldek (as amd64->x86_64 is for example) ? > > Since when amd64->x86_64 is handled by poldek anyway? see <200903101215.59792.g...@pld-linux.org> -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Saturday 28 of March 2009, Tomasz Pala wrote: > On Tue, Mar 10, 2009 at 08:19:44 +0100, Arkadiusz Miskiewicz wrote: > > Could some athlon*rpm owner see if upgrading athlon->i686 is nicely > > handled in poldek (as amd64->x86_64 is for example) ? > > Since when amd64->x86_64 is handled by poldek anyway? Look at th poldek changelog, I don't remember. You need to install poldek th and then other packages will be handled nicely. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tue, Mar 10, 2009 at 08:19:44 +0100, Arkadiusz Miskiewicz wrote: > Could some athlon*rpm owner see if upgrading athlon->i686 is nicely handled > in poldek (as amd64->x86_64 is for example) ? Since when amd64->x86_64 is handled by poldek anyway? -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Thu, Mar 12, 2009 at 12:11:35 +0100, Radoslaw Zielinski wrote: > The pain will be much bigger, than the gain [1]. > > $ perl -le 'map print, @INC' | grep /lib/ > /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi > /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi > /usr/lib/perl5/5.10.0/i686-pld-linux-thread-multi > > If we touch the first one, we'll screw over everyone who installed > something using CPAN.pm. People do that on production, a lot. We Let's just create symlinks... > [1] If we were to push this pain through (forcing everyone to rebuild > their custom-built perl stuff), it might be worth to consider > disabling ithreads, to get two gains in one go. That's about 10% > performance gain, and I have yet to encounter an application which > uses these. +1 -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
Pawel Golaszewski [12-03-2009 15:18]: > On Thu, 12 Mar 2009, Radoslaw Zielinski wrote: [...] >> -1: it's a major change and I can't see a good reason to warrant it. >> The pain will be much bigger, than the gain [1]. >> $ perl -le 'map print, @INC' | grep /lib/ >> /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi >> /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi >> /usr/lib/perl5/5.10.0/i686-pld-linux-thread-multi > We don't have to do it right now but on next bigger perl update? Why not? I'm cool with that. The thing I want to avoid is another needless clusterfuck, like the premature 5.10 update was. >> If we touch the first one, we'll screw over everyone who installed >> something using CPAN.pm. > Who cares /usr/local entry? It can stay in that form. Well, consistency does. > Anyway - can we add more paths to @INC? > It will fix all the problems. We could. Some distros used to do that (eg. SuSe, IIRC), years ago; they had really long @INC... The cost is more stat() calls when loading modules (two calls per one entry; one, if we also get rid of *.pmc -- I've never seen it used). Ugly, though. -- Radosław Zieliński pgpnXcLHToMLA.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Thu, 12 Mar 2009, Radoslaw Zielinski wrote: > > Why not try change it to something less problematic, for whole line: > > x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or maybe > > just "arch-pld-linux-thread-multi" (what about multilib in this > > moment?) > -1: it's a major change and I can't see a good reason to warrant it. > The pain will be much bigger, than the gain [1]. > > $ perl -le 'map print, @INC' | grep /lib/ > /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi > /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi > /usr/lib/perl5/5.10.0/i686-pld-linux-thread-multi We don't have to do it right now but on next bigger perl update? Why not? > If we touch the first one, we'll screw over everyone who installed > something using CPAN.pm. Who cares /usr/local entry? It can stay in that form. Anyway - can we add more paths to @INC? It will fix all the problems. -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Thu, 12 Mar 2009, Radoslaw Zielinski wrote:
> >> Whatever, but please don't invent some yet again "base" architecture
> >> prefixes (there is %{_target_base_arch} already). Anyway there is no
> >> need to use architecture name in %{_libdir} subdirectory (multilib is
> >> already handled by different %{_libdir} value).
> > Simple: /usr/lib/perl5/vendor_perl/5.8.0/
> /usr/lib/perl5/vendor_perl/5.10/ would do.
> [...]
> >> BTW, Debian doesn't use this part of path at all - just perl version
> >> number.
> > ...and we should follow that...
> No, we have no obligation to follow Debian about this.
Sure, but this is good thing.
--
pozdr. Paweł Gołaszewski jid:bluesjabbergdapl
--
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Thursday 12 March 2009 10:50:18 Pawel Golaszewski wrote:
> > Whatever, but please don't invent some yet again "base" architecture
> > prefixes (there is %{_target_base_arch} already). Anyway there is no
> > need to use architecture name in %{_libdir} subdirectory (multilib is
> > already handled by different %{_libdir} value).
>
> Simple:
> /usr/lib/perl5/vendor_perl/5.8.0/
>
> I like that.
>
> > BTW, Debian doesn't use this part of path at all - just perl version
> > number.
>
> ...and we should follow that...
1 from me (altho i already said it out :))
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Thu, Mar 12, 2009 at 12:26 PM, Arkadiusz Miskiewicz wrote: > > On Thursday 12 of March 2009, Radoslaw Zielinski wrote: > > Arkadiusz Miskiewicz [09-03-2009 22:41]: > > [...] > > > > > Opinions? Current plan is to do this on a incoming weekend. > > > > 1 week notice for deprecating an architecture is *harsh*, IMO. > > Current plan is to move maintainership of ppc to other person (sparky) and > disconnect ppc from th. It won't disappear. And what about athlon and i486? -- :: Witek Firlej :: :: Studencka wyprawa do Chin http://chiny2009.pl :: :: http://grizz.pl :: http://galeria.firlej.org :: jid: grizz//jabster.pl :: ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Thursday 12 of March 2009, Radoslaw Zielinski wrote: > Arkadiusz Miskiewicz [09-03-2009 22:41]: > [...] > > > Opinions? Current plan is to do this on a incoming weekend. > > 1 week notice for deprecating an architecture is *harsh*, IMO. Current plan is to move maintainership of ppc to other person (sparky) and disconnect ppc from th. It won't disappear. Compat symlinks will be there in th ftp for some time. Weekend deadline is no longer valid. New date will be announced some time later. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
2009/3/12 Radoslaw Zielinski : > Pawel Golaszewski [12-03-2009 09:50]: >> On Wed, 11 Mar 2009, Jakub Bogusz wrote: >>> BTW, Debian doesn't use this part of path at all - just perl version >>> number. >> ...and we should follow that... > No, we have no obligation to follow Debian about this. No, we should have obligations to follow ourselves - see ruby and python in PLD. -- Patryk Zawadzki ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
Arkadiusz Miskiewicz [09-03-2009 22:41]: [...] > Opinions? Current plan is to do this on a incoming weekend. 1 week notice for deprecating an architecture is *harsh*, IMO. -- Radosław Zieliński pgp9vKwsJUnG1.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
Pawel Golaszewski [12-03-2009 09:50]:
> On Wed, 11 Mar 2009, Jakub Bogusz wrote:
[...]
>> Whatever, but please don't invent some yet again "base" architecture
>> prefixes (there is %{_target_base_arch} already). Anyway there is no
>> need to use architecture name in %{_libdir} subdirectory (multilib is
>> already handled by different %{_libdir} value).
> Simple:
> /usr/lib/perl5/vendor_perl/5.8.0/
/usr/lib/perl5/vendor_perl/5.10/ would do.
[...]
>> BTW, Debian doesn't use this part of path at all - just perl version
>> number.
> ...and we should follow that...
No, we have no obligation to follow Debian about this.
--
Radosław Zieliński
pgpopbezKZAH0.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
Pawel Golaszewski [10-03-2009 21:58]: > On Tue, 10 Mar 2009, Elan Ruusamäe wrote: >> /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi > I'm wondering if we _really_ need to have that dir in this form? If I'll Probably not. > put perl module to that directory from i386 it'll simply work (or I'm > wrong?). I'm not sure if it'll always be correct, but likely yes. > Why not try change it to something less problematic, for whole > line: x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or > maybe just "arch-pld-linux-thread-multi" (what about multilib in this > moment?) -1: it's a major change and I can't see a good reason to warrant it. The pain will be much bigger, than the gain [1]. $ perl -le 'map print, @INC' | grep /lib/ /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi /usr/lib/perl5/5.10.0/i686-pld-linux-thread-multi If we touch the first one, we'll screw over everyone who installed something using CPAN.pm. People do that on production, a lot. We *might* consider doing a mv in a %trigger*, but that would violate the "packages do not touch /usr/local" rule. 2nd one... custom-built packages without directory dependencies will cause trouble, but that's probably not many people. I'm not sure if trees built with "perl Makefile.PL LIB=~/.lib" would be affected; if they were -- ouch, that's major. > I don't know how difficult is it, but it seems that rpm macros change and > rebuild perl will be enough (...and modules rebuild, of course :) ). Easy, no need to change the macros; just a couple of %defines in perl.spec. But do not do it without a *really* good reason and thinking it over. [1] If we were to push this pain through (forcing everyone to rebuild their custom-built perl stuff), it might be worth to consider disabling ithreads, to get two gains in one go. That's about 10% performance gain, and I have yet to encounter an application which uses these. It would be useful to talk to other distributors first, though. -- Radosław Zieliński pgpEsFqYuNwNZ.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Wed, 11 Mar 2009, Jakub Bogusz wrote:
> > > /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi
> >
> > I'm wondering if we _really_ need to have that dir in this form? If I'll
> > put perl module to that directory from i386 it'll simply work (or I'm
> > wrong?). Why not try change it to something less problematic, for whole
> > line: x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or
> > maybe just "arch-pld-linux-thread-multi" (what about multilib in this
> > moment?)
> Whatever, but please don't invent some yet again "base" architecture
> prefixes (there is %{_target_base_arch} already). Anyway there is no
> need to use architecture name in %{_libdir} subdirectory (multilib is
> already handled by different %{_libdir} value).
Simple:
/usr/lib/perl5/vendor_perl/5.8.0/
I like that.
> BTW, Debian doesn't use this part of path at all - just perl version
> number.
...and we should follow that...
--
pozdr. Paweł Gołaszewski jid:bluesjabbergdapl
--
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Wed, Mar 11, 2009 at 10:38 PM, Jakub Bogusz wrote:
> Whatever, but please don't invent some yet again "base" architecture
> prefixes (there is %{_target_base_arch} already).
>
> Anyway there is no need to use architecture name in %{_libdir}
> subdirectory (multilib is already handled by different %{_libdir} value).
>
> BTW, Debian doesn't use this part of path at all - just perl version number.
Just like we do with Python arch-specific packages.
--
Patryk Zawadzki
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tue, Mar 10, 2009 at 09:58:18PM +0100, Pawel Golaszewski wrote:
> On Tue, 10 Mar 2009, Elan Ruusamäe wrote:
> > /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi
>
> I'm wondering if we _really_ need to have that dir in this form? If I'll
> put perl module to that directory from i386 it'll simply work (or I'm
> wrong?). Why not try change it to something less problematic, for whole
> line: x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or
> maybe just "arch-pld-linux-thread-multi" (what about multilib in this
> moment?)
Whatever, but please don't invent some yet again "base" architecture
prefixes (there is %{_target_base_arch} already).
Anyway there is no need to use architecture name in %{_libdir}
subdirectory (multilib is already handled by different %{_libdir} value).
BTW, Debian doesn't use this part of path at all - just perl version number.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tue, Mar 10, 2009 at 21:58:18 +0100, Pawel Golaszewski wrote: > I'm wondering if we _really_ need to have that dir in this form? If I'll > put perl module to that directory from i386 it'll simply work (or I'm > wrong?). Why not try change it to something less problematic, for whole > line: x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or +1 > maybe just "arch-pld-linux-thread-multi" (what about multilib in this > moment?) > > I don't know how difficult is it, but it seems that rpm macros change and > rebuild perl will be enough (...and modules rebuild, of course :) ). ...and creating appropriate dir symlinks, as there's no way to upgrade all perl modules in many cases (like me). -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tue, 10 Mar 2009, Elan Ruusamäe wrote: > /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi I'm wondering if we _really_ need to have that dir in this form? If I'll put perl module to that directory from i386 it'll simply work (or I'm wrong?). Why not try change it to something less problematic, for whole line: x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or maybe just "arch-pld-linux-thread-multi" (what about multilib in this moment?) I don't know how difficult is it, but it seems that rpm macros change and rebuild perl will be enough (...and modules rebuild, of course :) ). -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tuesday 10 March 2009 15:24:05 Tomasz Pala wrote: > > as /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi is > > dirdep, and symlinkdep will not satisfy it (didn't test but i'm almost > > sure of this > > Who cares? I want to make perl working not rpm not-complaining. i'm just explaining. daaa! -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tue, Mar 10, 2009 at 15:15:10 +0200, Elan Ruusamäe wrote: > i suppose you wanted to make symlink: > /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi -> > /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi Yes. > but that will not fix such rpm dependency errors: > error: /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi is > required by installed perl-Date-Calc-5.4-1.i686 One last time: I don't care about these deps. Directory belongs to perl-dirs and I can install dozen of these. > as /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi is dirdep, > and symlinkdep will not satisfy it (didn't test but i'm almost sure of this Who cares? I want to make perl working not rpm not-complaining. -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tuesday 10 March 2009 12:40:40 Tomasz Pala wrote: > On Tue, Mar 10, 2009 at 12:18:58 +0200, Elan Ruusamäe wrote: > >> Partial solution: create symlinks for all /*athlon*/ directories to i686 > >> that are used. > > > > symlinks (afaik?) won't solve deps problem, the symlinks are not provided > > as directory deps. > > Read carefully - deps are not problem as they are met. It's the > different physical location of modules that cause problems. i suppose you wanted to make symlink: /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi -> /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi but that will not fix such rpm dependency errors: error: /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi is required by installed perl-Date-Calc-5.4-1.i686 as /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi is dirdep, and symlinkdep will not satisfy it (didn't test but i'm almost sure of this as /etc/httpd/httpd.conf dirdep was not solved by symlink in apache-base) -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tue, Mar 10, 2009 at 12:18:58 +0200, Elan Ruusamäe wrote: >> Partial solution: create symlinks for all /*athlon*/ directories to i686 >> that are used. > > symlinks (afaik?) won't solve deps problem, the symlinks are not provided as > directory deps. Read carefully - deps are not problem as they are met. It's the different physical location of modules that cause problems. -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tuesday 10 March 2009 11:44:09 Tomasz Pala wrote: > Partial solution: create symlinks for all /*athlon*/ directories to i686 > that are used. symlinks (afaik?) won't solve deps problem, the symlinks are not provided as directory deps. -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tuesday 10 March 2009 11:02:30 Pawel Golaszewski wrote: > Bad idea this way. It will destroy many systems (look at perl dirs). > poldek:/all-avail> rsearch -f /i686/ > Przeszukiwanie pakietów..zrobione. > [...] > 367 package(s) found. could do something like metapackage-X11 exists, which provides the dir, but requires new dir. err, and conflicts all perl packages from old arch (<- sounds already bad idea) -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tuesday 10 March 2009 10:59:58 Tomasz Pala wrote:
> On Tue, Mar 10, 2009 at 08:19:44 +0100, Arkadiusz Miskiewicz wrote:
> > Could some athlon*rpm owner see if upgrading athlon->i686 is nicely
> > handled in poldek (as amd64->x86_64 is for example) ?
yes, some recent fixes in poldek (with me & patrys: poldek-upgrade-dist.patch)
actually allow such upgrade (no more platform name used in depsolving, but
pkg colour bits)
> Upgrading rpms in one thing, upgrading packages having sth in
> */athlon-pld-linux/* (like perl) is another.
if it's just to get "32bit" dep, like glibc(?) had, then it should be used as
glibc(%{_target_base_arch}), not glibc(%{_target_arch})
but indeed, gcc, and perl have platform name in module paths. should we just
change it to use lib vs lib64?
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tuesday 10 of March 2009, Tomasz Pala wrote: > On Tue, Mar 10, 2009 at 10:32:24 +0100, Arkadiusz Miskiewicz wrote: > > How is that possible? There are dependencies that won't allow random > > upgrading of architecture dependant parts. > > These dependencies either don't allow upgrading at all (are not met and > one has to use --nodeps), or simply doesn't work. I've had such problems > many times, ending up with clean (as for deps) but not working system. > Don't forget that i686 is a subset of athlon. That's because i686 and athlon had the same version-revisions. Upgrade should work fine if i686 will have bigger revisions than athlon AFAIK (untested of course). -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tue, Mar 10, 2009 at 10:32:24 +0100, Arkadiusz Miskiewicz wrote: > How is that possible? There are dependencies that won't allow random > upgrading > of architecture dependant parts. These dependencies either don't allow upgrading at all (are not met and one has to use --nodeps), or simply doesn't work. I've had such problems many times, ending up with clean (as for deps) but not working system. Don't forget that i686 is a subset of athlon. Don't ask me how, I didn't care, but it IS PITA. I'm not sure if I want to do this on my own workstation this way (absolutely not prepared nor tested). And remember: such painful upgrade -> less users and developers. Some people are tired of neverending chasing for working system, personally I know already 3 persons who dumped PLD and more standing in a queue. Partial solution: create symlinks for all /*athlon*/ directories to i686 that are used. -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tuesday 10 of March 2009, Pawel Golaszewski wrote: > On Tue, 10 Mar 2009, Arkadiusz Miskiewicz wrote: > > > > I'm considering dropping athlon architecture since I see no real > > > > gain over i686. athlon would be deleted from ftp and athlon->i686 > > > > symlink created. > > > > > > Bad idea this way. It will destroy many systems (look at perl dirs). > > > > "destroy", how so? > > poldek --upgrade > > ...few perl modules upgraded and system is not working How is that possible? There are dependencies that won't allow random upgrading of architecture dependant parts. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tue, 10 Mar 2009, Arkadiusz Miskiewicz wrote: > > > I'm considering dropping athlon architecture since I see no real > > > gain over i686. athlon would be deleted from ftp and athlon->i686 > > > symlink created. > > Bad idea this way. It will destroy many systems (look at perl dirs). > "destroy", how so? poldek --upgrade ...few perl modules upgraded and system is not working > > In athlon dir should stay only rpm package which will make all the > > required changes: > > - /etc/rpm/platform > > - poldek sources fixes > > - something with patckages arch-dependant (paths, some hardcoded things). > That's way works for me, too. Of course that rpm will be unmaintained later. Sure - what for to maintain it later? It will be used on next arch-switch (how many years? :) ). -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tuesday 10 of March 2009, Pawel Golaszewski wrote: > On Mon, 9 Mar 2009, Arkadiusz Miskiewicz wrote: > > I'm considering dropping athlon architecture since I see no real gain > > over i686. athlon would be deleted from ftp and athlon->i686 symlink > > created. > > Bad idea this way. It will destroy many systems (look at perl dirs). "destroy", how so? > In athlon dir should stay only rpm package which will make all the > required changes: > - /etc/rpm/platform > - poldek sources fixes > - something with patckages arch-dependant (paths, some hardcoded things). That's way works for me, too. Of course that rpm will be unmaintained later. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Mon, 9 Mar 2009, Arkadiusz Miskiewicz wrote: > I'm considering dropping athlon architecture since I see no real gain > over i686. athlon would be deleted from ftp and athlon->i686 symlink > created. Bad idea this way. It will destroy many systems (look at perl dirs). poldek:/all-avail> rsearch -f /i686/ Przeszukiwanie pakietów..zrobione. [...] 367 package(s) found. Anyway - at least /etc/rpm/platform has to be fixed. In athlon dir should stay only rpm package which will make all the required changes: - /etc/rpm/platform - poldek sources fixes - something with patckages arch-dependant (paths, some hardcoded things). If we will make some nice way to do arch-switch it will be prepared for future moves -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tue, Mar 10, 2009 at 08:19:44 +0100, Arkadiusz Miskiewicz wrote: > Could some athlon*rpm owner see if upgrading athlon->i686 is nicely handled > in poldek (as amd64->x86_64 is for example) ? Upgrading rpms in one thing, upgrading packages having sth in */athlon-pld-linux/* (like perl) is another. -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Tuesday 10 of March 2009, Przemyslaw Iskra wrote: > On Mon, Mar 09, 2009 at 10:41:12PM +0100, Arkadiusz Miskiewicz wrote: > > I'm considering dropping athlon architecture since I see no real gain > > over i686. athlon would be deleted from ftp and athlon->i686 symlink > > created. > > Personally I use "athlon", but for binary crap only, which is built for > i386/i586 anyways, so I'm OK with dropping it. Could some athlon*rpm owner see if upgrading athlon->i686 is nicely handled in poldek (as amd64->x86_64 is for example) ? > > > The other platform is ppc. There is unforuntately close to zero > > developers solving ppc related bugs :-( ppc would be moved to unsupported > > or something like unofficial sparc (AIDA) as seen on ftp. Someone would > > have to step in to maintain this. > > Even tho I'm not very acrive (lately), I could step up as ppc maintainer > when it becomes AIDA. > > I could be fixing the packages I use, or if someone asks me nicely to > fix some (payment in goats no longer accepted). All the packages that > build cleanly on main th archs and have no history of being problematic > on powerpc would be send to ppc builder as well. If some package starts > to give problems and there would be noone to fix it, it would be > banned from ppc builder and last package in main repository would be > kept until its bependencies become broken. Then it would be deleted from > main without prior warning. > > What you think about such solution ? Works for me. After it disappears from Th I don't care about it (unless I'll become owner of some ppc again, which is unlikely). -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
On Mon, Mar 09, 2009 at 10:41:12PM +0100, Arkadiusz Miskiewicz wrote:
>
> I'm considering dropping athlon architecture since I see no real gain over
> i686. athlon would be deleted from ftp and athlon->i686 symlink created.
Personally I use "athlon", but for binary crap only, which is built for
i386/i586 anyways, so I'm OK with dropping it.
> The other platform is ppc. There is unforuntately close to zero developers
> solving ppc related bugs :-( ppc would be moved to unsupported or something
> like unofficial sparc (AIDA) as seen on ftp. Someone would have to step in to
> maintain this.
Even tho I'm not very acrive (lately), I could step up as ppc maintainer
when it becomes AIDA.
I could be fixing the packages I use, or if someone asks me nicely to
fix some (payment in goats no longer accepted). All the packages that
build cleanly on main th archs and have no history of being problematic
on powerpc would be send to ppc builder as well. If some package starts
to give problems and there would be noone to fix it, it would be
banned from ppc builder and last package in main repository would be
kept until its bependencies become broken. Then it would be deleted from
main without prior warning.
What you think about such solution ?
--
Sparky{PI] -- Przemyslaw _ ___ _ _ ... LANG...Pl..Ca..Es..En
/) ___ ___ _ _ || Iskra | | _ \| | | : WWWppcrcd.pld-linux.org
\\| -_)'___| ||^'||//\\// < | _/| | | : JID..sparkyjabberes.org
(/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mailsparkypld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Th: dropping athlon and maybe deprecating ppc?
I'm considering dropping athlon architecture since I see no real gain over i686. athlon would be deleted from ftp and athlon->i686 symlink created. The other platform is ppc. There is unforuntately close to zero developers solving ppc related bugs :-( ppc would be moved to unsupported or something like unofficial sparc (AIDA) as seen on ftp. Someone would have to step in to maintain this. Opinions? Current plan is to do this on a incoming weekend. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
