From: Andrea F. <an...@op...> - 2009-07-15 20:09:15
|
Hi guys, i'm to suggest you something really really intresting from my side. You may don't know, but OBS (openSUSE Build Service) is able to provide a packaging/debugging platform for a lot of distros. I think that the project X11:lxde can become he official lxde.org repository for several distros. deb based: Debian Etch Debian Lenny *Buntu 6.06 to 9.04 rpm based: mandriva 2008 - 2009 fedora 10 - 11 RHEL 4 - 5 suse 10.3 - 11.1 what do you think about it? Andrea -- ------------------------------------------ Andrea Florio QSI International School of Brindisi Sys Admin openSUSE-Education Administrator openSUSE Official Member (anubisg1) Email: an...@op... Packman Packaging Team Email: an...@li... Web: http://packman.links2linux.org/ Cell: +39-328-7365667 ------------------------------------------ |
From: Christoph W. <chr...@go...> - 2009-07-16 07:26:38
|
Am Mittwoch, den 15.07.2009, 22:05 +0200 schrieb Andrea Florio: > Hi guys, i'm to suggest you something really really intresting from my side. > > > You may don't know, but OBS (openSUSE Build Service) is able to provide > a packaging/debugging platform for a lot of distros. > > I think that the project X11:lxde can become he official lxde.org > repository for several distros. > > deb based: > > Debian Etch > Debian Lenny > *Buntu 6.06 to 9.04 > > rpm based: > mandriva 2008 - 2009 > fedora 10 - 11 > RHEL 4 - 5 > suse 10.3 - 11.1 > > what do you think about it? OBS is good for developers to provide packages for different distributions without to much hassle. However the quality of these packages is not really good in most cases IMO. People focus on their favorite distribution, but don't really care about others. For example I focus on rpm and it's been a while since I last build a deb. So I have no idea if/how Debian's packaging guidelines have changed in the meantime. We are in the lucky position to have dedicated package maintainers for all distributions you mentioned, so packages are available in the distributions itself and users don't need to add another package repository of unknown quality. If there is a distro or a package missing, it's most likely due to missing requirements. When I was doing RHEL builds last week, I noticed that many packages required a newer version of GTK2, wich is no problem for Fedora, but for RHEL. I guess the same might apply for Ubuntu 6.06 or Debian Etch. To summ it up: OSM is a good tool, but LXDE is happy to not really need it at the current point. > Andrea Kind regards, Christoph |
From: Christoph W. <chr...@go...> - 2009-07-19 14:09:41
|
Hi, apologies for the late reply. Am Donnerstag, den 16.07.2009, 14:12 +0200 schrieb Andrea Florio: > Christoph Wickert ha scritto: > > > OBS is good for developers to provide packages for different > > distributions without to much hassle. However the quality of these > > packages is not really good in most cases IMO. > > The package quality is due to packager to to OBS itsealf, ^^^ I guess the words "and not" are missing here, right? It depends on the packager, not on OBS. That's exactly what I said: People focus on a particular distro and it's impossible to know the guidelines and oddities of each and every other Linux. > obs just > provide a chroot enviroment where build you packages plus some post > build, quality checks on the package (spec file for example) and code, > like the gcc lint i post or checks on .desktop and init scripts and so on. Yes, and these things are also distribution specific. They depend on the versions of gcc and desktop-file-utils. What causes an error on SUSE may be perfectly fine for Fedora - and contrariwise. > > People focus on their favorite distribution, but don't really care about others. For example I > > focus on rpm and it's been a while since I last build a deb. So I have > > no idea if/how Debian's packaging guidelines have changed in the > > meantime. > > You can just write the spec file for your own distribution, following > you distro guidelines, (really we can use distro specific obs macros, > and create a multidistro spec file, for example: > > %if 0%{?fedora_version} == 11 > fedora 11 stuffs here > %endif > > %if 0%{?suse_version} == 1110 > suse 11.1 stuffs here > %endif ) This still is based on the assumption that a packager knows all the different guidelines from all distributions. I doubt that this is possible. > more infos here: > > http://en.opensuse.org/Build_Service/cross_distribution_package_how_to I know how to use macros, but since I'm not using SUSE I hardly don't know anything about the distro itself, so I'm not a good SUSE packager. And I have no SUSE here, so I have no idea what these macros resolve to. Let me give you some more examples: * package names and naming guidelines * License tag: On SUSE it's ok to use "GPL" for the License tag. On Fedora we are much stricter about licenses, because differen versions of licenses are not compatible. So we devide into GPLv2, GPLv2+, GPLv3 and GPLv3+. * Tags in genereal, e.g. "Group": Fedora and SUSE use different values for them. * Categories for menu entries and and the whole menu structure * Scriptlets: In Fedora we use a lot of scriptlets not used in SUSE, for example for desktop-file-install. On SUSE this is not needed, because SUSE has %suse_update_desktop_file. If you take all these differences into account, you will end up with a spec with lots of conditionals, which is way harder to maintain than a distribution specific spec/rules. What's the worth of a cross-distro spec file if we already have people working on the different distributions? > > We are in the lucky position to have dedicated package maintainers for > > all distributions you mentioned, so packages are available in the > > distributions itself and users don't need to add another package > > repository of unknown quality. > > I agree (in part), if lxde is provided into MAIN repos like mandriva, > than you can skip it, but if you are any way supposed to add a specific > repo, i think instead, that if all packagers works together, they > (including me) will have a greate chance to improve packages and use > other distro patches (if valid). Then these patches are no longer distro-specific and should be upstreamed into LXDE. > In other words, The packagers are still > the same, then the packages quality is still the same, No, because a packager may be an excellent on Debian but lousy on Mandriva. > but because all > packagers works together all of them can help each others and improve > all packages. What should this look like? If we had 5 people working on a spec file for all rpm-based distributions, these people need to agree on all the changes. Changes need to be discussed first, which requires knowledge about every single distro and slows down the whole process dramatically. Too many cooks spoil the broth. Regarding quality: What kind of QA does OBS offer? Is there an testing repository for users to test? Is there a way for users to give feedback. > > To summ it up: OSM is a good tool, but LXDE is happy to not really need > > it at the current point. > > > > OSM? can you explain it better? what's that? A typo. :( I meant OSB. I don't see what additional benefit OSB offers to LXDE. If we were looking for maintainers, I would agree with you, but LXDE already is available in most distros. Please tell me which one is missing in your opinion. I know for example RHEL is missing, but this is mostly due to the GTK version, so there is nothing OSB could do about it. Please don't get me wrong: I value your interest and your suggestion and I think that OSB is a good tool for some use cases but I doubt it is for LXDE. Regards, Christoph |
From: Andrew L. <an...@li...> - 2009-07-19 16:57:21
|
Hi, For my opinion, this platform sounds cool for authors to by pass distros maintainer and directly to users. But in debian we need someone responsible for the packaging, so we will repackage anyway for officially use for debian. If you want to provide debian support, please use directory name other than debian/. Cause it would cause more work for me as I would have to remove that while I am packaging. :) Thanks, -Andrew Christoph Wickert wrote: > Hi, > > apologies for the late reply. > > Am Donnerstag, den 16.07.2009, 14:12 +0200 schrieb Andrea Florio: >> Christoph Wickert ha scritto: >> >>> OBS is good for developers to provide packages for different >>> distributions without to much hassle. However the quality of these >>> packages is not really good in most cases IMO. >> The package quality is due to packager to to OBS itsealf, > ^^^ > I guess the words "and not" are missing here, right? It depends on the > packager, not on OBS. That's exactly what I said: People focus on a > particular distro and it's impossible to know the guidelines and > oddities of each and every other Linux. > >> obs just >> provide a chroot enviroment where build you packages plus some post >> build, quality checks on the package (spec file for example) and code, >> like the gcc lint i post or checks on .desktop and init scripts and so on. > > Yes, and these things are also distribution specific. They depend on the > versions of gcc and desktop-file-utils. What causes an error on SUSE may > be perfectly fine for Fedora - and contrariwise. > >>> People focus on their favorite distribution, but don't really care about others. For example I >>> focus on rpm and it's been a while since I last build a deb. So I have >>> no idea if/how Debian's packaging guidelines have changed in the >>> meantime. >> You can just write the spec file for your own distribution, following >> you distro guidelines, (really we can use distro specific obs macros, >> and create a multidistro spec file, for example: >> >> %if 0%{?fedora_version} == 11 >> fedora 11 stuffs here >> %endif >> >> %if 0%{?suse_version} == 1110 >> suse 11.1 stuffs here >> %endif ) > > This still is based on the assumption that a packager knows all the > different guidelines from all distributions. I doubt that this is > possible. > >> more infos here: >> >> http://en.opensuse.org/Build_Service/cross_distribution_package_how_to > > I know how to use macros, but since I'm not using SUSE I hardly don't > know anything about the distro itself, so I'm not a good SUSE packager. > And I have no SUSE here, so I have no idea what these macros resolve to. > > Let me give you some more examples: > * package names and naming guidelines > * License tag: On SUSE it's ok to use "GPL" for the License tag. > On Fedora we are much stricter about licenses, because differen > versions of licenses are not compatible. So we devide into > GPLv2, GPLv2+, GPLv3 and GPLv3+. > * Tags in genereal, e.g. "Group": Fedora and SUSE use different > values for them. > * Categories for menu entries and and the whole menu structure > * Scriptlets: In Fedora we use a lot of scriptlets not used in > SUSE, for example for desktop-file-install. On SUSE this is not > needed, because SUSE has %suse_update_desktop_file. > > If you take all these differences into account, you will end up with a > spec with lots of conditionals, which is way harder to maintain than a > distribution specific spec/rules. What's the worth of a cross-distro > spec file if we already have people working on the different > distributions? > >>> We are in the lucky position to have dedicated package maintainers for >>> all distributions you mentioned, so packages are available in the >>> distributions itself and users don't need to add another package >>> repository of unknown quality. >> I agree (in part), if lxde is provided into MAIN repos like mandriva, >> than you can skip it, but if you are any way supposed to add a specific >> repo, i think instead, that if all packagers works together, they >> (including me) will have a greate chance to improve packages and use >> other distro patches (if valid). > > Then these patches are no longer distro-specific and should be > upstreamed into LXDE. > >> In other words, The packagers are still >> the same, then the packages quality is still the same, > > No, because a packager may be an excellent on Debian but lousy on > Mandriva. > >> but because all >> packagers works together all of them can help each others and improve >> all packages. > > What should this look like? If we had 5 people working on a spec file > for all rpm-based distributions, these people need to agree on all the > changes. Changes need to be discussed first, which requires knowledge > about every single distro and slows down the whole process dramatically. > Too many cooks spoil the broth. > > Regarding quality: What kind of QA does OBS offer? Is there an testing > repository for users to test? Is there a way for users to give feedback. > >>> To summ it up: OSM is a good tool, but LXDE is happy to not really need >>> it at the current point. >>> >> OSM? can you explain it better? what's that? > > A typo. :( I meant OSB. I don't see what additional benefit OSB offers > to LXDE. If we were looking for maintainers, I would agree with you, but > LXDE already is available in most distros. Please tell me which one is > missing in your opinion. > > I know for example RHEL is missing, but this is mostly due to the GTK > version, so there is nothing OSB could do about it. > > Please don't get me wrong: I value your interest and your suggestion and > I think that OSB is a good tool for some use cases but I doubt it is for > LXDE. > > Regards, > Christoph > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list |
From: Andrea F. <an...@op...> - 2009-07-16 10:12:24
|
Christoph Wickert ha scritto: > OBS is good for developers to provide packages for different > distributions without to much hassle. However the quality of these > packages is not really good in most cases IMO. The package quality is due to packager to to OBS itsealf, obs just provide a chroot enviroment where build you packages plus some post build, quality checks on the package (spec file for example) and code, like the gcc lint i post or checks on .desktop and init scripts and so on. > People focus on their favorite distribution, but don't really care about others. For example I > focus on rpm and it's been a while since I last build a deb. So I have > no idea if/how Debian's packaging guidelines have changed in the > meantime. You can just write the spec file for your own distribution, following you distro guidelines, (really we can use distro specific obs macros, and create a multidistro spec file, for example: %if 0%{?fedora_version} == 11 fedora 11 stuffs here %endif %if 0%{?suse_version} == 1110 suse 11.1 stuffs here %endif ) more infos here: http://en.opensuse.org/Build_Service/cross_distribution_package_how_to for deb packages instead: http://en.opensuse.org/Build_Service/Deb_builds the easy thing is that for rpms you need a spec file, sources and 1 or more patches, you (the packager) have only to put all together in the obs, it will take care to use them. (the same happen with debs, you put control, dsc, changelog and patch files and obs wll build it) > We are in the lucky position to have dedicated package maintainers for > all distributions you mentioned, so packages are available in the > distributions itself and users don't need to add another package > repository of unknown quality. I agree (in part), if lxde is provided into MAIN repos like mandriva, than you can skip it, but if you are any way supposed to add a specific repo, i think instead, that if all packagers works together, they (including me) will have a greate chance to improve packages and use other distro patches (if valid). In other words, The packagers are still the same, then the packages quality is still the same, but because all packagers works together all of them can help each others and improve all packages. > If there is a distro or a package > missing, it's most likely due to missing requirements. When I was doing > RHEL builds last week, I noticed that many packages required a newer > version of GTK2, wich is no problem for Fedora, but for RHEL. I guess > the same might apply for Ubuntu 6.06 or Debian Etch. > i don't see the problem, you can just disable a particular repo/distro building > To summ it up: OSM is a good tool, but LXDE is happy to not really need > it at the current point. > OSM? can you explain it better? what's that? > > Kind regards, > Christoph > > Regards Andrea -- ------------------------------------------ Andrea Florio QSI International School of Brindisi Sys Admin openSUSE-Education Administrator openSUSE Official Member (anubisg1) Email: an...@op... Packman Packaging Team Email: an...@li... Web: http://packman.links2linux.org/ Cell: +39-328-7365667 ------------------------------------------ |