Re: Proposal on how to handle xorg include patches (WAS: Re: X Strike Force XOrg SVN commit: r28 - /)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Branden Robinson wrote: | On Wed, Oct 13, 2004 at 12:35:20AM -0400, Michel Dänzer wrote: | |I'm not sure this is really an issue at all. When a component moves to |its own module, it should have a more or less stable interface to other |modules. That interface should be preserved by any patches touching |several modules, so the parts for every module can really be considered |separate patches. | |Of course, I may be missing something or simply have a misconception |about how the modularization is supposed to work... | | | I was initially skeptical, too, but Fabio wants to work on this and I don't | mind it. | | In any case, he can't help but develop some good experience with the XOrg | tree, and that's a valuable thing to have. | | I'm not inclined to try and pass judgement on Fabio's approach being right | or wrong until sarge releases. | I am indeed very interested in everybody opinion. It's not my toy. If my approach has a wrong desing and i don't notice, i much rather to know it now rather than later. True that it is still probably too early to say but i won't kill people for expressing their ideas :-) Fabio - -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBdMxYhCzbekR3nhgRAu2xAJ4g2TAxFfBqUD5/iU0CqDh3A6Nn/gCgi+ii v+YZsrWEtimvIPX0+uVTIKM= =0B00 -END PGP SIGNATURE-
Re: Proposal on how to handle xorg include patches (WAS: Re: X Strike Force XOrg SVN commit: r28 - /)
On Wed, Oct 13, 2004 at 12:35:20AM -0400, Michel Dänzer wrote: I'm not sure this is really an issue at all. When a component moves to its own module, it should have a more or less stable interface to other modules. That interface should be preserved by any patches touching several modules, so the parts for every module can really be considered separate patches. Of course, I may be missing something or simply have a misconception about how the modularization is supposed to work... I was initially skeptical, too, but Fabio wants to work on this and I don't mind it. In any case, he can't help but develop some good experience with the XOrg tree, and that's a valuable thing to have. I'm not inclined to try and pass judgement on Fabio's approach being right or wrong until sarge releases. -- G. Branden Robinson| Never attribute to human stupidity Debian GNU/Linux | that which can be adequately [EMAIL PROTECTED] | explained by GNU Libtool. http://people.debian.org/~branden/ | -- Scott James Remnant signature.asc Description: Digital signature
Re: Proposal on how to handle xorg include patches (WAS: Re: X Strike Force XOrg SVN commit: r28 - /)
On Wed, Oct 13, 2004 at 12:35:20AM -0400, Michel D?nzer wrote: Of course, I may be missing something or simply have a misconception about how the modularization is supposed to work... Fabio's approach emulates modularity from a monolithic tree, and is a pretty good one. The big problem is that the modular tree, as it stands right now, isn't quite ready right now. So, I'm working on making it ready, by merging as many patches as possible back, by making the build system work, et al, and then packaging the results. -- Daniel Stone[EMAIL PROTECTED] Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: Proposal on how to handle xorg include patches (WAS: Re: X Strike Force XOrg SVN commit: r28 - /)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michel Dänzer wrote: | On Tue, 2004-10-12 at 09:20 +0200, Fabio Massimo Di Nitto wrote: | |X Strike Force SVN Repository Admin wrote: | || +| || +|-- xorg-source-include -- xorg-include | |Hi XSF, |~ as you might have noticed, we started (at low priority) working on |X.org packages. | | | Great! | | | |Modularized tree (files are not patched coming from xorg-source-include): | |xc/include/libfoo/foo.h |xc/include/libbar/bar.h | |lsdiff libfoo/debian/patch/XXXfix_foo_due_to_baz.diff |~ xc/include/libfoo/foo.h | |lsdiff libbar/debian/patch/XXXfix_bar_due_to_baz.diff |~ xc/include/libbar/bar.h | |(note that there might no be xc/include/libfoo at all) | |bang! now both libfoo and libbar either will not compile properly due to |foo.h and bar.h not being patched at the same time or they will not work |properly for the same reason. | | | I'm not sure this is really an issue at all. Neither am I houenstly. I am still not there at a point to build stuff around. All these are only ideas and possible problems that we might face and we definetly want to be ready to address immediatly. | When a component moves to | its own module, it should have a more or less stable interface to other | modules. That interface should be preserved by any patches touching | several modules, so the parts for every module can really be considered | separate patches. I agree. | | Of course, I may be missing something or simply have a misconception | about how the modularization is supposed to work... | | This step of the modularization is fake. What I am trying to achive is to split the source in small sources and be able to build everything out of the small pieces. Consider it the an exploration of the modularization. It might work as well as it might end up into full crap. It is definetely worth a try. In the worst case we will know that it is not possible yet. Fabio - -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBbjRwhCzbekR3nhgRAmvlAJ9laSCGAvUqa9hJY1zy/pM7dN0tuACgl0K6 Jy0RS+9Mcsl7esGB7eCSXFc= =iB/0 -END PGP SIGNATURE-
Re: Proposal on how to handle xorg include patches (WAS: Re: X Strike Force XOrg SVN commit: r28 - /)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Hellwig wrote: | On Tue, Oct 12, 2004 at 09:20:21AM +0200, Fabio Massimo Di Nitto wrote: | |-BEGIN PGP SIGNED MESSAGE- |Hash: SHA1 | |X Strike Force SVN Repository Admin wrote: | || +| || +|-- xorg-source-include -- xorg-include | |Hi XSF, |~ as you might have noticed, we started (at low priority) working on |X.org packages. | |The commits you are seeing now are only the proof of concept that we |will use to split the tree in a sort of modularized way, using an |approach close to the way in which our Debian kernel is packaged. |There are some differences, but at this point in time, until the concept |is not proved to be working, are somehow irrelevant. | | | Note that the -source vs -image package in the kernel are an sbolute | maintaine horror, I would strongly advice against repeating that | mistake. | | The main reason why we are using this approach is because X doesn't evolve as fast as the kernel and it is the only way at the moment to simulate X.org modularized tree. In this way each time a package gain its own independency, it will be dropped silently from the -source- package and a new version of independent-source orig.tar.gz will be uploaded. The good thing is that all of this can be done without ftp-master manual intervention (other than the first package approval). Fabio - -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBbKgxhCzbekR3nhgRAoMIAJ0bsJ7j907oHjWHtbx4v9ACkjVInQCfUB6j nKjErse8HeY8gLaa1FuQ6A8= =hnD6 -END PGP SIGNATURE-
Proposal on how to handle xorg include patches (WAS: Re: X Strike Force XOrg SVN commit: r28 - /)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 X Strike Force SVN Repository Admin wrote: | +| | +|-- xorg-source-include -- xorg-include Hi XSF, ~ as you might have noticed, we started (at low priority) working on X.org packages. The commits you are seeing now are only the proof of concept that we will use to split the tree in a sort of modularized way, using an approach close to the way in which our Debian kernel is packaged. There are some differences, but at this point in time, until the concept is not proved to be working, are somehow irrelevant. I am now facing a problem that i would like to discuss with the list. Example scenario: monolithic tree: xc/include/libfoo/foo.h xc/include/libbar/bar.h lsdiff debian/patch/XXXfix_foo_bar_due_to_baz.diff ~ xc/include/libfoo/foo.h ~ xc/include/libbar/bar.h and this is supposed to compile and work fine, since the new version of the libraries are patched and built at the same time. - - Modularized tree (files are not patched coming from xorg-source-include): xc/include/libfoo/foo.h xc/include/libbar/bar.h lsdiff libfoo/debian/patch/XXXfix_foo_due_to_baz.diff ~ xc/include/libfoo/foo.h lsdiff libbar/debian/patch/XXXfix_bar_due_to_baz.diff ~ xc/include/libbar/bar.h (note that there might no be xc/include/libfoo at all) bang! now both libfoo and libbar either will not compile properly due to foo.h and bar.h not being patched at the same time or they will not work properly for the same reason. Now I can see four possibilities to unroll this problem: 1 the xorg package that generates all the xorg-source packages will ship ~ a patched tree. ~ - Pro: all the patches will be applied at the same time to the entire ~tree therefor it's easier to track them. ~ - Con: patches will not be splitted (and this will only the delay the ~problem when a source will gain its own independency. ~ - Con: it requires an upload of more than 100MB of arch: all packages ~each time we change a patch, that is a waste of bw to all the ~mirror. ~ - Con: xorg packages will need a more strict control of build-deps, ~that will mostlikely end up in confusion and temporary FTBFS. 2 Create a package called xorg-patched-include from xorg-source-include ~ used only internally as build-dep. ~ - Pro: all the patches will still be applied at the same time in one ~place. ~ - Pro: it will avoid a 100MB upload each time. ~ - Con: patches are still not splitted. ~ - Con: xorg packages will still need a more strict control of ~Build-deps. 3 Split the includes at subfolder level (same as programs/ or libs/) ~ - Pro: all patches will be available within the proper package. ~ - Pro: patches will be splitted. ~ - Pro: less confusion for people that will try to build xorg from ~sources. ~ - Pro: much deeper control of what build-dep on what and why. ~ - Con: duplicate patches. We will have to keep in sync more patches ~in different packages. (given of course that the above scenario is ~true and probably it is.) ~ - Con: more xorg-source-include-* packages, but they are handled ~automatically. ~ - Con: possibly more complex build-deps. 4 Leave the includes all in one source package as it is now ~ (xorg-source-include) ~ - Pro: all patches will be available within the proper package. ~ - Pro: patches will be splitted. ~ - Pro: less confusion for people that will try to build xorg from ~sources. ~ - Con: duplicate patches. Considering that our target is to get the source as splitted as possible I think that solution number 3 will be the best one to let a source gain its own independency as fast as possible. tho it will need more maintaince our side, but i am pretty sure that we can manage to script these kind of sanity checks. I will be pretty much glad to hear other opinions so that the work can move forward. Thanks Fabio - -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBa4WyhCzbekR3nhgRAjCrAKCE8tfrORlzRYiDPnjUX64W6OiJVACfQX1o pLcrHZ86GTAwnjeBjy8Cy1g= =4v4m -END PGP SIGNATURE-
Re: Proposal on how to handle xorg include patches (WAS: Re: X Strike Force XOrg SVN commit: r28 - /)
On Tue, Oct 12, 2004 at 09:20:21AM +0200, Fabio Massimo Di Nitto wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 X Strike Force SVN Repository Admin wrote: | +| | +|-- xorg-source-include -- xorg-include Hi XSF, ~ as you might have noticed, we started (at low priority) working on X.org packages. The commits you are seeing now are only the proof of concept that we will use to split the tree in a sort of modularized way, using an approach close to the way in which our Debian kernel is packaged. There are some differences, but at this point in time, until the concept is not proved to be working, are somehow irrelevant. Note that the -source vs -image package in the kernel are an sbolute maintaine horror, I would strongly advice against repeating that mistake.
