Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
So what are exact rules at the moment?
What if someone wants to create another branch of distro?
I'd like to know that too. When I've created Titanium I was keeping
separate branches on some specs. That was baad, because I wasn't merging
my changes/updates to HEAD. So I started using %if %{pld_release}
macros instead and keeping my changes on HEAD. For over two years no one
had problems with that.
Now I guess if someone wants to create/maintain his branch of distro he
will be forced to work on separate branch in case of even smallest
differences in spec because Someone(tm) is too lazy to workout few %if
macros. Nothing bad with that. Titanium is unofficial and I can't do
anything about official PLD decisions except for my vote in CDG.
I'm only afraid what next step will be.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Wed, Feb 3, 2010 at 11:02 AM, Marcin Krol h...@limanowa.net wrote:
So what are exact rules at the moment?
What if someone wants to create another branch of distro?
I'd like to know that too. When I've created Titanium I was keeping
separate branches on some specs. That was baad, because I wasn't merging
my changes/updates to HEAD.
But that's not our fault, is it? :)
So I started using %if %{pld_release}
macros instead and keeping my changes on HEAD. For over two years no one
had problems with that.
If I reckon well, I had problems with that, because such laziness
leads to situations
like we have now. It was discusses twice or something in the past.
My point is - in the past it was decided that distro branches are kept
on separate
branches and it worked in case of Ra, Ac and Th (aka nest)
Now, if you want new rules then please state them. Or we will end up
with mess on
HEAD.
Cheers,
w
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Wed, Feb 03, 2010 at 12:02:07 +0100, Marcin Krol wrote:
my changes/updates to HEAD. So I started using %if %{pld_release}
macros instead and keeping my changes on HEAD. For over two years no one
had problems with that.
I have a problem - assume I want to rebuild some package in Ti-way. How?
Now I guess if someone wants to create/maintain his branch of distro he
will be forced to work on separate branch in case of even smallest
differences in spec because Someone(tm) is too lazy to workout few %if
macros. Nothing bad with that. Titanium is unofficial and I can't do
anything about official PLD decisions except for my vote in CDG.
I'm only afraid what next step will be.
If all the %ifs would have to be removed, you can always switch bconds
in rpmmacros of Ti builder.
--
Tomasz Pala go...@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: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
Number of specs where %if %{pld_release} macros are used isn't that
big and doesn't make modifying them that hard. I don't ask anyone to
edit/adjust/fix Titanium part of such specs, just forget its there and
focus on Th part.
This is what bconds are for. Their state is the only thing that should
be TI-related.
Seems fine for me, but it will still be trashing HEAD for some people
I'm afraid. The only thing that will change is %if. Instead of
%if %{pld_release} == ti
something
%else
something different
%endif
we will have
%if %{with titanium}
something
%else
something different
%endif
And again we will end in discussion that HEAD is unreadable, uneditable,
messed up etc. etc.
I'm thinking about branching those few specs and removing all Titanium
changes from HEAD + adding single %if %{pld_release} macro with
blocker to be sure that no one will be able to build HEAD version on
Titanium.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Wednesday 03 February 2010 13:02:07 Marcin Krol wrote:
So I started using %if %{pld_release}
macros instead and keeping my changes on HEAD. For over two years no one
had problems with that.
and there are no problems if the spec stays processible after that, it was
reminder that it's maybe gone too far already...
On Wednesday 03 February 2010 13:22:53 Tomasz Pala wrote:
Now, if you want new rules then please state them. Or we will end up
with mess on HEAD.
Assuming these changes are irrevelant to all of Th us. Take a look at
iceweasel.spec - that's the way it should be done and IMHO could.
i tend to agree here, distro specific differences accomplished with bconds,
rest of the spec is like regular bconds, openssl.spec could be lead to same
level if some FEATURE_dir macro is introduced and similar with_ncursesw
added. just adding %if pld_brand and copying back block from previous spec
reivision is what grinds my gears.
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
I'd like to know that too. When I've created Titanium I was keeping separate branches on some specs. That was baad, because I wasn't merging my changes/updates to HEAD. But that's not our fault, is it? :) Yes it is. Hawk working on Titanium and not merging his changes because of -ENOTIME - bad, some developers are unhappy that they must merge to HEAD themselves. So Hawk starts working on HEAD separating Titanium specific changes - also bad, some developers are unhappy that Titanium stuff is on HEAD despite its separated and doesn't affect Th at all. Thats how it looks right now from my point of view. My point is - in the past it was decided that distro branches are kept on separate branches and it worked in case of Ra, Ac and Th (aka nest) I'll be honest. Moving all specs to Titanium branch will mean death of my fork. I simply have no time to track each and every spec for changes to be merged or branch point to be moved. I don't have as much time as I had in the past to maintaint PLD. Thats my problem, I agree. Now, if you want new rules then please state them. Or we will end up with mess on HEAD. Its either bconds as suggested and we will still have same mess on HEAD or branching few specs and adding Titanium blockers on HEAD. I'm fine with both solutions. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Wed, Feb 3, 2010 at 11:51 AM, Marcin Krol h...@limanowa.net wrote: I'd like to know that too. When I've created Titanium I was keeping separate branches on some specs. That was baad, because I wasn't merging my changes/updates to HEAD. But that's not our fault, is it? :) Yes it is. Hawk working on Titanium and not merging his changes because of -ENOTIME - bad, some developers are unhappy that they must merge to HEAD themselves. So Hawk starts working on HEAD separating Titanium specific changes - also bad, some developers are unhappy that Titanium stuff is on HEAD despite its separated and doesn't affect Th at all. Well, until I had to clean up mess in some of the spec files and non-building packages. Not speaking about some stupid commit war around ac/ti/th/whatever changes, which would not happen if appropriate changes were kept on a branch. [...] My point is - in the past it was decided that distro branches are kept on separate branches and it worked in case of Ra, Ac and Th (aka nest) I'll be honest. Moving all specs to Titanium branch will mean death of my fork. I simply have no time to track each and every spec for changes to be merged or branch point to be moved. I don't have as much time as I had in the past to maintaint PLD. Thats my problem, I agree. Probably I missed some discussion on irc or pld-devel-pl... but what is exact purpose of Titanium? Why it started in first place? w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
Probably I missed some discussion on irc or pld-devel-pl... but what is exact purpose of Titanium? Why it started in first place? There are two main reasons: 1. To have stable distro with actual software. Ac had and has too old software for me and Th is still light years away from being stable (in my terms of stability). 2. To have absolute freedom about deciding what is good and what is bad for distribution. It wasn't and still is not possible with official PLD I'm afraid. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Wed, Feb 03, 2010 at 12:33:58 +0100, Marcin Krol wrote:
Seems fine for me, but it will still be trashing HEAD for some people
I'm afraid. The only thing that will change is %if. Instead of
%if %{pld_release} == ti
[...]
we will have
%if %{with titanium}
No, you didn't understand. It's not supposed to be '--with titanium' but
'--with alternative_option_for_this_package', just like in iceweasel.
--
Tomasz Pala go...@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: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Wed, Feb 3, 2010 at 2:19 PM, Tomasz Pala go...@polanet.pl wrote:
On Wed, Feb 03, 2010 at 12:33:58 +0100, Marcin Krol wrote:
Seems fine for me, but it will still be trashing HEAD for some people
I'm afraid. The only thing that will change is %if. Instead of
%if %{pld_release} == ti
[...]
we will have
%if %{with titanium}
No, you didn't understand. It's not supposed to be '--with titanium' but
'--with alternative_option_for_this_package', just like in iceweasel.
You mean system xulrunner, right?
w
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Wed, Feb 03, 2010 at 14:26:51 +, Artur Wroblewski wrote: No, you didn't understand. It's not supposed to be '--with titanium' but '--with alternative_option_for_this_package', just like in iceweasel. You mean system xulrunner, right? Yes. And there could be --without FHS for openssl and --without extcolors in ncurses. It happens that all the 3 cases are also my preferences, I'd like to keep them available regardles of some weird branch-specific macro. -- Tomasz Pala go...@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: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Wed, Feb 03, 2010 at 16:12:27 +0100, Marcin Krol wrote: No, you didn't understand. It's not supposed to be '--with titanium' but '--with alternative_option_for_this_package', just like in iceweasel. It will look kind of funny... --with var_lib_openssl for openssl.spec? I If you prefer such a funny name... Just think what it is for and name it, I already proposed --without FHS but it can be sth like 'ac_compat'. think I prefer branches then for those few specs and blockers on HEAD. ...then I'll restore these options as bconds, because I don't agree with Th-line either and you'll end up with not maintained branches. BTW any chances on iceweasel 3.6? -- Tomasz Pala go...@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: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
BTW any chances on iceweasel 3.6? Yes. I'm working on Iceweasel, Icedove and Iceape upgrades, but my time for PLD is limited right now. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Tuesday 02 February 2010 16:04:46 shadzik wrote:
Author: shadzik Date: Tue Feb 2 14:04:46 2010 GMT
Module: packages Tag: HEAD
Log message:
- make it build on Titanium, try not to break build on Th - let's see if
that succeeded
...
+%if %{pld_release} != ti
%attr(755,root,root) %ghost /%{_lib}/libtinfow.so.6
%attr(755,root,root) %{_libdir}/libncursesw.so.*.*
%attr(755,root,root) %ghost %{_libdir}/libncursesw.so.5
%attr(755,root,root) %{_libdir}/libtinfow.so.*.*
%attr(755,root,root) %ghost %{_libdir}/libtinfow.so.5
+%else
+%attr(755,root,root) %ghost /%{_lib}/libtinfow.so.5
+%attr(755,root,root) %ghost /%{_lib}/libncursesw.so.5
+%endif
this has exceeded sane amount of the nesting level of ifdefs, please move the
branch specific spec to a dedicated branch, both branches be nicer and more
easier to update. there isn't so much changes in a spec that such complexity
of following the conditions (to verify nothing got broken after a change)
pays off.
same applies to openssl.spec
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Tuesday 02 February 2010 16:23:41 Bartosz Świątek wrote:
2010/2/2 Elan Ruusamäe g...@pld-linux.org:
On Tuesday 02 February 2010 16:04:46 shadzik wrote:
Author: shadzik Date: Tue Feb 2 14:04:46 2010 GMT
Module: packages Tag: HEAD
Log message:
- make it build on Titanium, try not to break build on Th - let's see if
that succeeded
...
+%if %{pld_release} != ti
%attr(755,root,root) %ghost /%{_lib}/libtinfow.so.6
%attr(755,root,root) %{_libdir}/libncursesw.so.*.*
%attr(755,root,root) %ghost %{_libdir}/libncursesw.so.5
%attr(755,root,root) %{_libdir}/libtinfow.so.*.*
%attr(755,root,root) %ghost %{_libdir}/libtinfow.so.5
+%else
+%attr(755,root,root) %ghost /%{_lib}/libtinfow.so.5
+%attr(755,root,root) %ghost /%{_lib}/libncursesw.so.5
+%endif
this has exceeded sane amount of the nesting level of ifdefs, please move
the branch specific spec to a dedicated branch, both branches be nicer
and more easier to update. there isn't so much changes in a spec that
such complexity of following the conditions (to verify nothing got broken
after a change) pays off.
same applies to openssl.spec
This is the way Hawk told me to deal with such problems - exactly not
to have dozens of branches - therefore I'm dealing with them that way.
Two or three more conditions doesn't make it less readable. Request
rejected.
hawk: tell your internörs to reconsider trashing the HEAD, kernel.spec's are
in branches, why can't this be, this is no longer a simple change.
to shadzik: do not remove cc: when replying even if you post gets rejected.
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea...
On Tuesday 02 February 2010 17:41:40 Artur Wroblewski wrote:
2010/2/2 Elan Ruusamäe g...@pld-linux.org:
On Tuesday 02 February 2010 16:23:41 Bartosz Świątek wrote:
2010/2/2 Elan Ruusamäe g...@pld-linux.org:
On Tuesday 02 February 2010 16:04:46 shadzik wrote:
Author: shadzik Date: Tue Feb 2 14:04:46 2010
GMT Module: packages Tag: HEAD
Log message:
- make it build on Titanium, try not to break build on Th - let's see
if that succeeded
...
+%if %{pld_release} != ti
%attr(755,root,root) %ghost /%{_lib}/libtinfow.so.6
%attr(755,root,root) %{_libdir}/libncursesw.so.*.*
%attr(755,root,root) %ghost %{_libdir}/libncursesw.so.5
%attr(755,root,root) %{_libdir}/libtinfow.so.*.*
%attr(755,root,root) %ghost %{_libdir}/libtinfow.so.5
+%else
+%attr(755,root,root) %ghost /%{_lib}/libtinfow.so.5
+%attr(755,root,root) %ghost /%{_lib}/libncursesw.so.5
+%endif
this has exceeded sane amount of the nesting level of ifdefs, please
move the branch specific spec to a dedicated branch, both branches be
nicer and more easier to update. there isn't so much changes in a spec
that such complexity of following the conditions (to verify nothing
got broken after a change) pays off.
same applies to openssl.spec
This is the way Hawk told me to deal with such problems - exactly not
to have dozens of branches - therefore I'm dealing with them that way.
Two or three more conditions doesn't make it less readable. Request
rejected.
hawk: tell your internörs to reconsider trashing the HEAD, kernel.spec's
are in branches, why can't this be, this is no longer a simple change.
to shadzik: do not remove cc: when replying even if you post gets
rejected.
If I reckon well we had discussion about that in the past. And here goes
the mess. Enjoy cleaning it up.
Best regards,
w
if you refer to the %py_version vs %pld_release comparision, then these
are totally different, threads, large poritions conditioned out over the spec
became headache to read eventually. especially if you need to update only
one condition branch, that's what is this email thread initiated.
anyway, note sent to hawk who seems to control the decisions, so lets wait
what he decides.
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
