Mailinglist Archive: opensuse-buildservice (113 mails)

< Previous Next >
BS provides no benefit for me
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Mon, 29 May 2006 12:53:24 +0200
  • Message-id: <447AD2A4.1080603@xxxxxxxxx>
(moving this thread from smart-maintainers to opensuse-buildservice, I
think its content is more relevant here ;))

Christoph Thiel wrote:
> On Mon, 29 May 2006, Pascal Bleser wrote:
>>>> And Christoph because you might want to check whether you've got all
>>>> of those patches in the SL10.1/Factory smart RPM (but if you do a new
>>>> build, please don't have a release >= 25 that supersedes my package
>>>> again ;D).
>>> I'll check our smart package soon. Now, that we have the openSUSE
>>> Build Service up and running, we might consider working on the smart
>>> package together and share the maintainership. How about that?
>> I don't think so.
>> Well, we could, and I would base my own spec on the one in the build
>> service (though there wouldn't be any benefit for me, rather the
>> opposite, it would be more work).
>> The buildservice is not interesting to me ATM because
>> 1) the buildservice is not advertised anywhere as a repository for
>> packages (as opposed to > 50% of SUSE Linux users already using my
>> repository)
> We will be promoting the Build Service very aggressively soon. A re-design
> of the web frontend is on the way and the commandline tools already work
> very well (IMO).

OK. But the web frontend currently is only targeted at packagers
AFAIK. I really mean the end-user side of things.
Don't know whether there are plans to also design an interface that's
usable for end-users. And if so, what those plans look like.

Unfortunately, it's all happening behind the SUSE curtain :(

Navigating the BS repositories/directories is currently a PITA because
there's no real concept for how those should be organized (I *don't*
think putting stuff into home:/home:pbleser/smart would be a good
idea, for example).

There must be a single summary page that lists all the projects and
packages that are in the BS.

>> 2) I preconfigure my smart package with a lot of channel files,
>> including packman and guru so... legal issues ?
> Indeed -- but I'd rather split those channel files into a new package and
> have smart depend on it (or suggest it). I might even be able to put a
> channel package into SUSE Linux, with a reduced set of channels.

Mmmmmyeah, that would be a technical option, but not a good thing for
end-users IMO. When I look at the current situation with 10.1 and its
broken zypp, end-users are already struggling to install my smart RPM
(mostly because it depends on rpm-python, that is not installed by
default) and have to jump a few hoops because YaST2 or rug just won't
work on their system:

So adding another package/dependency would make things even more complex.

And from a technical POV, if I put those channels into, say,
smart-suse-channels.rpm, you can't really make smart.rpm depend on it
because smart-suse-channels.rpm won't be in the Build Service.

>> At some point, smart will be in the packman repository, and then the
>> BuildService becomes even less interesting:
>> - no mirror infrastructure yet
> This is WIP at the moment. We already push to and another
> mirror. Check out

Yes, I've read Adrian's mail about that. Good news :)

>> - no web frontend as with packman [1]
>> [1] see
> ;)

No kidding, it's really an advantage of hosting it at Packman instead
of the Build Service ;)

>> But as for maintaining the smart package for Factory, yes, we could do
>> it together in the BuildService (if that's already feasible with the
>> current implementation of BS) so when I add patches to my package, I can
>> also add them to the smart project in the BuildService.
> Exactly -- have you tried osc (the python cmdline client to the openSUSE
> Build Serivce)?

I gave it a quick shot which was not very concluding, but mostly
because I didn't know where to create my projects (sent a mail to
opensuse-packaging two weeks ago but no reply, and it's been
reorganized anyway).
I definitely have to give it another shot. osc is obviously the
approach that I prefer and suits me best, a simple CLI client (and not
a web frontend).
Thanks to Peter for writing it :)

I don't want to discard or discredit your efforts on the BuildService,
but I really don't see any advantage for me in using it at the moment,
it's rather the opposite:
- I build for SUSE 9.1 -> 10.1, and only 10.0, 10.1 and Factory are in
the BS as of now (AFAIK)
- no web frontend for end-users as I'll have with Packman

Note that I don't care at all about building for other distributions.

What would make the BS more compelling to me would be to have a ppc
build target (and providing what I'm missing, above ;)).

Of course, that's my very personal POV, in the light of building
packages that are not provided at all on SUSE Linux or that could only
be built as a crippled subset because of potential legal/patent issues.
It's a totally different case concerning packages that are already in
the distribution, that I could co-maintain directly and that are built
as full-fledged because they're not in the gray legal/patent realm.

-o) Pascal Bleser
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>

< Previous Next >