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
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxde-list
