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 23:14:47 +0200
  • Message-id: <451300C7.3080704@xxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Oakley wrote:
> On Wednesday 20 September 2006 9:38 pm, Pascal Bleser wrote:
>> 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.
>
> That's actually a good reason to use the buildservice. You only have to make
> one search to avoid duplication.

What search function ? ;)

>> 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)
>
> I try very hard as well. I won't distribute something that I know you guys
> already have.
>
> So, how do we reconcile?

Good question.
An ideal solution would be to have some sort of package database with a
search frontend and it would then show a reference to the repository
that has it. Problem is, it cannot be hosted @ novell/opensuse.org
because it would reference packages like ... you know which ones ;)

>> 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,
>
> Isn't this the point of the buildservice? What's the problem?

No I really mean communication between human beings (or bots ;)).
Email, IRC, whatever.

...
>> 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)
>
> That's fine, I use your Amarok builds. However, it would be nice to be able to
> subscribe to an "Amarok" repository and not worry about something I don't
> want sneaking in.

Yes and no.
I'm really not sure it's the best approach.
For someone who wants to use the latest versions of a lot of packages,
that's a lot of repositories to subscribe to.
No issue for somewhat experienced users, but every day I can see people
struggle to even add the packman repository to their yast2.
Yes, it's dead simple, no, they can't do it without assistance.

>> - 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.
>
> Yes, there are always newer versions of any software. However, some of us may
> want newer versions of one package, but not others. The buildservice makes
> separation of projects or topics really easy.

To me, the build service misses some key features to make it usable by
beginners (the stuff I posted earlier in this thread).

+ there are a lot of packages we cannot maintain in the BS for the
reasons we all know

...
>> "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 ?
>
> No. I use your Amarok. I was talking about ALSA, and stuff like imlib2,
> libogg, and curl that has the potential to break other software since they're
> linked to. There's no good reason to upgrade these things willy-nilly. If
> there's a bug, it should be reported to SUSE.

That's one option, but not necessarily everyone's preference.
As long as it doesn't break the .so number, newer version is fine with
me, at least for some packages.

>> 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" ?
>
> Yes, but not everyone uses Factory, which does have the latest versions of
> *all* software. The ability to have separate repositories is the key here.

I don't know, I don't think so. Or rather, it depends... lol
If you look at KDE, Subversion or Apache, sure.
If you look at my repository... how could I possibly split
$ find . -type f -name '*.rpm' -a ! -name '*.src.rpm'|wc -l
10660
?

>> 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.
>
> Ideally, they could get them from one place, in categories, like the build
> service.

Possibly. But it's not easy to use as it is now for less experienced users.
(btw, we really miss installation_sources -a on 10.1)

>> 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
>> name-calling.
>
> As you said above:
>
>> liferea: 10.1 ships 1.0, latest stable is 1.0.23, latest beta is 1.1.5
>
> You're saying that larger numbers are better. I don't doubt that there are
> bugfixes and new features, but those things can have unintended effects. How
> about a real world example?
>
> A few years ago, a vulnerability was found in a version of openssh. SUSE and
> the other major vendors fixed the problem and patched the existing version.
> The openssh guys responded by releasing a new version with a part of the auth
> system re-worked. This new, "better", version had an even bigger
> vulnerability. Everybody who blindly upgraded had to upgrade again, while
> those of us who played it safe were just fine.

James, I know this.

But for that example, I can give you 5-15 packages every single day that
do not break nor create new security issues.
A single case hardly makes a rule.

>> 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.
>
> I was not trying to criticize your abilities. You all do a great job and I
> *do* benefit from your work. I just can't help but cringe when I see newer
> versions of base libraries in your repositories. It's too risky for me.

Categorization and single repos is tough for me to manage. Way too many
packages and not enough categories for all that.

>> 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,
>
> They were all part of GNOME, so users adding his repository knew what kind of
> packages they were getting, and how much of their system was affected.
>
> This is one of the reasons I like the buildservice. You can separate things
> into different repositories so everybody is clear about what they're getting.
>
>> it is. But still, dubbing the packman repository as being bleeding-edge
>> stuff that nukes anyone but experts' systems is both untrue and somewhat
>> offensive.
>
> I didn't say that. I just said that some upgraded packages have possible
> unintended side-effects, which can break things. It happened to me with
> Packman's alsa.

Which is why I said: shit happens (and will happen again).

cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFFEwDHr3NMWliFcXcRAkDWAJ9oftSFGGmBYT3gTPaqkyN5vpnQuwCgijB+
VDbSVlHeA+iQZ3m1xXjU4Ac=
=LUqd
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups