Mailinglist Archive: opensuse-buildservice (252 mails)

< Previous Next >
Re: [opensuse-buildservice] Help needed for Packaging
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Thu, 21 Sep 2006 02:38:47 +0200
  • Message-id: <4511DF17.70407@xxxxxxxxx>
Hash: SHA1

James Oakley wrote:
> On Tuesday 19 September 2006 8:07 pm, Pascal Bleser wrote:
>> The only thing I don't appreciate is that a lot of packages the packman
>> team or I maintain (often since quite some time) show up in the BS,
>> maintained by other people, without even getting a notice.
>> Thank you, how nice.
>> That's not how we community packagers do it. We talk to each other, try
>> to avoid duplicate work,
> You didn't contact me when you decided to release perl-XML-Twig,
> perl-XML-XPath, and python-lxml packages, which I've been distributing since
> SUSE 8.1, 9.1, and 10.0, respectively.
> I was also not contacted when Packman released xmltv and mmpython packages,
> which I've been distributing, with proper names, since SUSE 8.0 and 8.2,
> respectively.
> Thank you, how nice.

James, I said we *try*.
You tell me 3 packages, I can probably give you a good dozen (at the
very least) that are being built in the BuildService and where I never
got a single notification, whatsoever.

At least the following people try hard to avoid duplication or
merge/reconcile when it happens:
- - the packman team
- - oc2pus (just joined the packman team)
- - my repository
(and that probably accounts for 70% of the SUSE Linux packages coming
from the community, so that's already quite good)

We definitely need better communication across community packagers.. or
rather, all packagers. I really hoped openSUSE would be a channel for
that, but it didn't happen, though I tried to trigger it a few times
(probably not hard enough, or maybe the time wasn't right, yet).
Aren't the community packagers a critical aspect of a healthy Linux
distribution ? Yeah, at least we agree on that.
Maybe we should try to revive opensuse-packaging@xxxxxxxxxxxx

>> mostly try to consolidate our work in the
>> packman infrastructure in order to provide the best possible experience
>> for SUSE users out there. Especially as the BS likes to generate high
>> release numbers, _which voids our work_ (and I would really like to
>> insist on this point).
> That brings me to another point, you guys have been releasing newer versions
> of packages that SUSE distribute, for no good reason, without the testing
> that the SUSE packages get. I remember the time back in the apt days that a
> simple 'apt upgrade' caused me to get a newer version of alsa than the SUSE
> kernel had. All of a sudden, I couldn't compile programs against ALSA because
> the kernel/userspace headers didn't match. At that point I had to add rules
> to apt's not-for-the-mere-mortal config files to keep it from unnecessarily
> upgrading packages.
> I *never* put packages that SUSE already has in my repos. I can't afford the
> time to do the testing necessary to make sure I'm not breaking somebody's
> setup. I'll leave the version-itis to the Gentoo folks, thank you.

That's your point of view and your policy as a packager, great, why not.

Actually there is a real demand for having
- - packages that may not be provided by SUSE Linux or the Build Service
(we know what those packages are)
- - packages that are not part of SUSE Linux (but not for the reason above)
- - newer versions of packages shipped with SUSE Linux

Let me pick a few good examples from my repository:
- - amarok: the SUSE package is outdated (1.3.8, newest is 1.4.3), and the
BS package is crippled (no MP4 tagging support, no MySQL support, no
PostgreSQL support)
- - liferea: 10.1 ships 1.0, latest stable is 1.0.23, latest beta is 1.1.5
- - lftp: 10.1 ships 3.4.0, latest stable is 3.5.4
- - xchat: 10.1 ships 2.6.1, latest stable is 2.6.6
and I could go on.

And I won't even mention older SUSE versions like 10.0 or 9.3, for which
we provide up-to-date packages.

We all know what the policy of SUSE Linux is wrt that (no new versions,
backport patches when fixing security issues or severe bugs), and that's
perfectly fine, understandable and probably the only way to have a
consistent and tested distribution.
Nevertheless, newer versions of widely used projects (as the ones above,
but there are a lot more) sport a lot of enhancements and new features.

"for no good reason" - wth ? Are you really telling me that no one
should have amarok 1.4.3 as an option, but stick with 1.3.8 instead
because it has been tested by the SUSE QA team ? I'd knew a lot of
people who would switch distros if it was like that.
The "latest stable KDE" repository in the Build Service is also used by
a significant number of users... "for no good reason" ?

If people want to stick with a fully tested system that works fine for
them, only use the stock SUSE packages, fine.
If people want the features of newer versions of some packages they use
often, then they can get them from packman, guru, oc2pus, and many others.

I don't see what this has to do with "versionitis". Our work is a vital
part of the SUSE Linux ecosystem. Labeling that "versionitis" is just
It's almost surprising, but given how few time I can invest into testing
the packages I maintain and how many people use them, issues are really,
really rare, and the same is to be said for packman. So I guess that 1)
the developers are doing a pretty good job, 2) we're possibly not that
bad at packaging.
Actually, when I take a quick look at the packages in my repository, I'd
say 95% of them are packages that are _not_ shipped with SUSE Linux.

And as far as sticking with SUSE package versions and not breaking
systems, I can remember usr-local-bin gnome packages being poison for
anyone not really experienced with it, so none of us is perfect,
packaging errors or unforeseeable consequences can always happen (even
with packages made by the SUSE team) given how much of a complex matter
it is. But still, dubbing the packman repository as being bleeding-edge
stuff that nukes anyone but experts' systems is both untrue and somewhat

James, I don't even understand why I'm telling you this, you already
know all that stuff.

- --
-o) Pascal Bleser
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v The more things change, the more they stay insane.
Version: GnuPG v1.4.2 (GNU/Linux)

To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups