Plan for python upgrade

cyf3732

那这样看起来情况有可能会变得很囧阿……

难免有错

According to the number of emails in my inbox (which has reached well
into double figures), my plan for the python 2.6 and 3.0 upgrade is
rather controversial.  So, I thought that I would add some more
justification here and point out that if people want to comment on the
strategy they can do so by replying to public mailing lists because it
is getting repetitive I will no longer be replying individually to people.

Here are the possible upgrade strategies.

Plan 1:
    python = python3.0
    python2 = python2.6

Plan 2:
    python = python2.6
    python3 = python3.0
   
These are the advantages/disadvantages of these plans as far as I can
see.  Many programs point at "/usr/bin/python" or "/usr/bin/env
python".  For Plan 1, the /usr/bin/python binary is python3.0 so that
involves rebuilding packages and changing them to point at "python2".  
For some, this is as simple as rebuilding.  Others require a simple sed
statement.  Also, with Plan 1, anything with a python depends/optdepends
will need rebuilt.  So, Plan 1 involves *a lot* more rebuilding that
Plan 2 (around 125 packages vs 47 packages in [extra]).

Plan 2 will also require adjusting programs built against python3 to
point at /usr/bin/python3 in their scripts and changing the dependency
to python3 so this is a now versus later issue.  Also, with Plan 2, at
some later stage we will want the /usr/bin/python binary to be
python-3.x and probably to keep a legacy python-2.x package.  That tells
me, that Plan 2 requires moving to Plan 1 at a later time.

So in summary:
Plan 1 - Big rebuild now.  People complain "Allan broke it"...
Plan 2 - Medium rebuild now, drawn out transition, followed by
medium/big rebuild later. People complain "Allan broke it" long term...

I am going to go for Plan 1 unless someone convinces me the Plan 2 is a
better plan _long_ term.  I prefer short term pain for long term benefit
rather than long term pain for short term benefit.

Cheers,
Allan

superjet

arch里打包的多数是死也要追新、当小白的主，只管往自己的车上配套最新材料，不合拍的话就来个车架子走起来也行，至于搭车的则看其手艺了，所以经常会有旧零件装不到新车架的问题，arch的跑车也经常是带着窟窿在跑

没有multi-lib的结构和debian里update-alternatives类似机制，用户越多，arch缺乏稳健和兼蓄并收的弊端也就会越明显，因为并不是所以好用的东东等会疯狂更新的，比如pdftk一度很长时间在arch里无法编译，也不是所有的用户只用kde、gnome等更新、维护都比较简单的少数东东，多年的小众发行版的帽子估计还会戴很久

hubert_star

楼上的注意了！

我们上面在讨论的是之后python的计划，可能会在明年，也可能会在后年才会开始进入系统，仅仅是计划而已，你不看吗？

另外，所谓的追新，仅仅是加入了testing仓库才这样吧？extra里面的东西都很稳定，而且相关关系明确。

说新，其实arch不加testing的话相当于当前流行的发行版，而加了testing无非相当于流行发行版的测试版而已，ubuntu不是半年出一次吗？跟archlinux的testing区别不大。

还有pdftk怎么就编译不通过了？编译不通过无非就是依赖库版本不匹配而已，自己解决一下就可以了。

还有，multi-lib不是不能解决，而update-alternatives更是垃圾，很简单用符号搞定的东西，非要用所谓的alternatives来做。

现在我不知道我的系统还是不是arch，很多东西都是自己编译的，从这点上讲，arch和gentoo一样（当然LFS那就更不用说了），更像是自己的系统，维护好了，非常棒，如果不是实际使用了一段时间，还真看不出这点。

hubert_star

从你的言语中可以看出你用的是ubuntu

与所用用ubuntu的人一样，只是看井口巴掌大那么一片天

jupiter5188

pdftk不用也罢，现在的inkscape直接支持PDF导入并修改，只是稳定性还有待加强。

superjet

本人是没用过ubuntu的人。。。

除非你不用community才会很少碰到坏的包，即使是只用extra，中间也有着恨烂的包，比如很长没更新的openswan-klips是没法用的，更别说aur上中众多的半成品了，再者打包的主也不会全不用testing，所以由此带来的???.so也屡见不鲜

至于是否只是计划，以arch的风格，咱们跟着看就行了

而pdftk的问题，没跟踪过的相关话题的话，就说来话长了，其功能在linux下能替代的还是很少。至于debian的update-alternatives是否垃圾，最少debian用户的零头也比arch的多可以说明些问题，毕竟不是所有人都是傻瓜

cyf3732

Post by hubert_star;1890258
从你的言语中可以看出你用的是ubuntu

与所用用ubuntu的人一样，只是看井口巴掌大那么一片天

既然是技术讨论，就不要过分涉及个人属性的问题，不管别人的取向是什么。我想，这应该是每一个 linuxer 应具备的素质。

superjet 只是表达对 py 升级的不理解，并没有针对某一个人，回到就事论事的范畴更明智

superjet

呵呵，大过节的没啥必要吵来吵去的了，也没意思，就事论事大家都用不着臆来臆去了，毕竟决定权在别人手里，大家不管喜欢的还是不喜欢的静观其变好了，然后再对应去想对策，终级的目的还是一个好用的系统

难免有错

superjet好大的怨念啊。