[yast-devel] Building UI libs vs. zypp vs. dev. environment (Was: how to mark *.ybc file outdated?)
Ahoj!
I'm afraid I can't start mailing concise requests for improvement of y2 development environment.
Reading through your mails, you are very well able to describe whats wrong and what must be improved.
So speak up and raise the topic ! Thats what yast-devel, yast-internal, team meeting minutes, weekly reports and FATE are for.
So I'm speaking up and rising the topic :) This time it has nothing to do with .ybc files, but with UI libs and zypp (and no, it's not about app layer at all ;-) ) The problem: * To test a bugfix, I need to build yast2-ncurses. * To build y2-ncurses, I need libzypp headers (happen to lose them somehow during numerous upgrades) * Tried libzypp svn checkout and then cmake & make, but oh my ... it wants to download tons of satsolver cr ... I mean, data ;-) * Trying to skip this by going directly into libzypp/zypp subdir, it complains about missing libsatsolver-devel * OK, trying to compile sat-solver stuff - no success, I miss some rpmdb stuff * I'm giving up and going to have a joint ;-) Had I done 'rpm -ivh --force libzypp-devel.rpm' (force, because otherwise I would need libzypp.rpm as well and would never get out of rpm dependency hell) at the very beginning, I'd save at least half an hour of time and quite a lot of nerves But that's not a system solution. After all, I'm fixin' just an error in UI, what the heck do I need sat-solver for? So, either I'm doing something wrong or something is rotten in the state of Denmark ... Would splitting yast2-ncurses (as well as yast2-qt) package into pure UI part and package-management part and building those two separately help? Would some 'install header files from this subdir only' tool in libzypp makefiles help? I don't know Anyway, I'm speaking up and raising the topic :) frozenB. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter
Dne Wednesday 24 of October 2007 18:41:11 Katarina Machalkova napsal(a):
Ahoj!
I'm afraid I can't start mailing concise requests for improvement of y2 development environment.
Reading through your mails, you are very well able to describe whats wrong and what must be improved.
So speak up and raise the topic ! Thats what yast-devel, yast-internal, team meeting minutes, weekly reports and FATE are for.
So I'm speaking up and rising the topic :) This time it has nothing to do with .ybc files, but with UI libs and zypp (and no, it's not about app layer at all ;-) )
The problem: * To test a bugfix, I need to build yast2-ncurses.
To test the fix locally, do you need to build whole yast2-ncurses? The package selector is already a separate library (from different reasons), you can compile only the other stuff quite easily, or? (from some reasons, unlike qt, NCPkgTable.* still reside in the src directory of the NCurses UI, isn't it a bug of the split?) (this does not intend to be a universal answer for all building issues, just for this particular one) Jiri
* To build y2-ncurses, I need libzypp headers (happen to lose them somehow during numerous upgrades) * Tried libzypp svn checkout and then cmake & make, but oh my ... it wants to download tons of satsolver cr ... I mean, data ;-) * Trying to skip this by going directly into libzypp/zypp subdir, it complains about missing libsatsolver-devel * OK, trying to compile sat-solver stuff - no success, I miss some rpmdb stuff * I'm giving up and going to have a joint ;-)
Had I done 'rpm -ivh --force libzypp-devel.rpm' (force, because otherwise I would need libzypp.rpm as well and would never get out of rpm dependency hell) at the very beginning, I'd save at least half an hour of time and quite a lot of nerves
But that's not a system solution. After all, I'm fixin' just an error in UI, what the heck do I need sat-solver for? So, either I'm doing something wrong or something is rotten in the state of Denmark ...
Would splitting yast2-ncurses (as well as yast2-qt) package into pure UI part and package-management part and building those two separately help? Would some 'install header files from this subdir only' tool in libzypp makefiles help? I don't know Anyway, I'm speaking up and raising the topic :)
frozenB.
-- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz
[I changed the subject since it is a general problem] * Katarina Machalkova <kmachalkova@suse.cz> [Oct 24. 2007 18:41]:
Ahoj!
Hallo !
The problem: * To test a bugfix, I need to build yast2-ncurses. * To build y2-ncurses, I need libzypp headers (happen to lose them somehow during numerous upgrades) * Tried libzypp svn checkout and then cmake & make, but oh my ... it wants to download tons of satsolver cr ... I mean, data ;-) * Trying to skip this by going directly into libzypp/zypp subdir, it complains about missing libsatsolver-devel * OK, trying to compile sat-solver stuff - no success, I miss some rpmdb stuff * I'm giving up and going to have a joint ;-)
Well, there is no easy solution to this. The current way of development is - trunk for everything - branches for product maintenance and your example shows that this is not sufficient. What you (and probably others too, I wonder why noone else speaks up) need is a 'dedicated bugfix branch' not influenced by ongoing development in other areas. In other words: More branches. Although branching is relatively easy with svn, merging is not and thats why we limit the number of branches. My proposal would be to use a different scm (source code management) system which makes branching and merging less painful, e.g. 'git' Git would certainly help with scenarios you described (because the sat-solver kids would play in their own sandbox ;-)) while also making YaST development more open towards community contribution (esp. because one doesn't need write access to a central repository). The downside is a complete new concept towards source code management which isn't that easy to grasp. But there are lots of tools, documentation and hints available to make this step as easy as possible. Comments anyone ?
But that's not a system solution. After all, I'm fixin' just an error in UI, what the heck do I need sat-solver for? So, either I'm doing something wrong or something is rotten in the state of Denmark ...
Well, actually both. You can do the bugfix by branching off an earlier revision of libzypp (before sat-solver, e.g. just immediately after 10.3) and merge it back after testing. For the general case, see above. [...]
Anyway, I'm speaking up and raising the topic :)
Good, thank you ! Klaus -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thu, Oct 25, Klaus Kaempf wrote:
The current way of development is
- trunk for everything - branches for product maintenance
and your example shows that this is not sufficient.
What you (and probably others too, I wonder why noone else speaks up) need is a 'dedicated bugfix branch' not influenced by ongoing development in other areas.
In other words: More branches.
If you don't want/need to follow the development in one branch then you can use use e.g. the devel package, or leave your local copy at a certain revision. I guess the 'UI guys'n'girls' would prefer to not being in need to compile the sublibs at all. sat-solver e.g. is just a build time requirement. If a libzypp-devel package was used, you won't see it at all. Things might be easyer if - instead of checkig out a certain SVN revision - one could simply order the -devel package based on revision "XYZ". Sort of internal -devel package build service, shiping the packages including header files and libs (incl. the *.so.*), prepared to be installed in /usr/local. get-devel-pkg libzypp [-r7623] -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
You can prepare a chroot environment with a maintained product, and mount your source directory there using bind, and then chroot and compile inside. I managed to get all the knowledge from Thomas Fehr and Gabi, and it is in my inbox. I am willing to release it, in exchange of processing and a nice wiki page about it :-) Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thu, Oct 25, Duncan Mac-Vicar Prett wrote:
You can prepare a chroot environment with a maintained product, and mount your source directory there using bind, and then chroot and compile inside.
I managed to get all the knowledge from Thomas Fehr and Gabi, and it is in my inbox.
I am willing to release it, in exchange of processing and a nice wiki page about it :-)
Unfortunately I will be on vacation, starting some hours from now ;-)) Tschuess, Thomas Fehr -- Thomas Fehr, SuSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Markus Rex, HRB 16746 (AG Nürnberg) Tel: +49-911-74053-0, Fax: +49-911-74053-482, Email: fehr@suse.de GPG public key available. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thursday 25 October 2007 15:11:09 Thomas Fehr wrote:
Unfortunately I will be on vacation, starting some hours from now ;-))
Which turns me into a monopoly of information, and therefore more incentive for whose needing it for offering turning it into a nice wiki page :-) Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thursday 25 October 2007 15:29, Duncan Mac-Vicar Prett wrote:
On Thursday 25 October 2007 15:11:09 Thomas Fehr wrote:
Unfortunately I will be on vacation, starting some hours from now ;-))
Which turns me into a monopoly of information, and therefore more incentive for whose needing it for offering turning it into a nice wiki page :-)
Not quite a monopoly. I used the scripts of Thomas as basis to create the CruiseControl[1]-magic[2] that creates the chroot for a defined distribution copies the checkout there (that is the only difference, bind mounting should be easy to add) and builds within the chroot environment. I can help you with the wiki page and provide scripts :) [1]: http://cruisecontrolrb.thoughtworks.com/ [2]: http://cit32.suse.de:3333 (only SUSE-internal) Ciao, Daniel -- J. Daniel Schmidt <jdsn@suse.de> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi guys!
If you don't want/need to follow the development in one branch then you can use use e.g. the devel package, or leave your local copy at a certain revision.
Thanks a bunch for advice, it's just some sort of pavlovian conditioning to always check out trunk. Checking out an older revision that compiles painlessly is a sufficient workaround for me. Another solution would be to separate pkg management part from UI library. That is partially done, but in ncurses, some files not being used elsewhere than in the packager still dwell outside pkg/ subdir. Frankly, I did not investigate further why it is so :)
Things might be easyer if - instead of checkig out a certain SVN revision - one could simply order the -devel package based on revision "XYZ".
Sort of internal -devel package build service, shiping the packages including header files and libs (incl. the *.so.*), prepared to be installed in /usr/local.
get-devel-pkg libzypp [-r7623]
Cool thing :) I wonder how many people would appreciate and frequently use something like that. B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter
participants (7)
-
Duncan Mac-Vicar Prett -
J. Daniel Schmidt -
Jiri Srain -
Katarina Machalkova -
Klaus Kaempf -
Michael Andres -
Thomas Fehr