FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Build System

 
 
LinkBack Thread Tools
 
Old 10-14-2008, 02:23 AM
"Martin Langhoff"
 
Default Tying yum to a package "stream"?

OLPC's XS ships a number of patched packages. The packages are
normally built with a different "stream" or "flavour" (they don't say
"f9" but "xs05") and sit in a special repository.

Is there a good way to ensure revisor/yum prefers the packages from
the xs stream or repo over the standard F9 release or update packages,
even if the f9 package is newer?

(In the APT/Debian world the closest parallel would be setting apt
preferences to have biased priorities -- aka Pin -- on a label or a
component.)

cheers,



m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 10-14-2008, 02:27 AM
seth vidal
 
Default Tying yum to a package "stream"?

On Tue, 2008-10-14 at 15:23 +1300, Martin Langhoff wrote:
> OLPC's XS ships a number of patched packages. The packages are
> normally built with a different "stream" or "flavour" (they don't say
> "f9" but "xs05") and sit in a special repository.
>
> Is there a good way to ensure revisor/yum prefers the packages from
> the xs stream or repo over the standard F9 release or update packages,
> even if the f9 package is newer?
>
> (In the APT/Debian world the closest parallel would be setting apt
> preferences to have biased priorities -- aka Pin -- on a label or a
> component.)

you can use yum's priorities plugin to achieve similar results.
Just as in the apt-world configuring priorities/pinning for
longterm/widespread use is a frelling nightmare.

-sv


--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 10-14-2008, 02:57 AM
"Martin Langhoff"
 
Default Tying yum to a package "stream"?

On Tue, Oct 14, 2008 at 3:27 PM, seth vidal <skvidal@fedoraproject.org> wrote:
> you can use yum's priorities plugin to achieve similar results.

It's a bit simpler than apt but I can sure work with this. Thanks!

> Just as in the apt-world configuring priorities/pinning for
> longterm/widespread use is a frelling nightmare.

:-) -- well stated.

If people mess with the repo configs we provide, install random rpms
or play their Heavy Metal Rock records backwards, they void their
warranty.

cheers,



m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 10-14-2008, 03:24 AM
James Antill
 
Default Tying yum to a package "stream"?

On Tue, 2008-10-14 at 15:57 +1300, Martin Langhoff wrote:
> On Tue, Oct 14, 2008 at 3:27 PM, seth vidal <skvidal@fedoraproject.org> wrote:
> > you can use yum's priorities plugin to achieve similar results.
>
> It's a bit simpler than apt but I can sure work with this. Thanks!
>
> > Just as in the apt-world configuring priorities/pinning for
> > longterm/widespread use is a frelling nightmare.
>
> :-) -- well stated.
>
> If people mess with the repo configs we provide, install random rpms
> or play their Heavy Metal Rock records backwards, they void their
> warranty.

To expand on what Seth is saying, if you are doing this on your local
developer workstation etc. ... feel free to do whatever you want to
override the normal behaviour from the repos. (that's what the features
are there for).

But if you are going to ship a repo to end users which requires/uses
the yum-priority plugin (or excludes, or whatever), then the simple
advise I would give you is: _don't_.
Instead clone the Fedora repo. removing the packages you want to
"override", or even better get your changes into Fedora.

--
James Antill <james@fedoraproject.org>
Fedora

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 10-14-2008, 03:48 AM
"Martin Langhoff"
 
Default Tying yum to a package "stream"?

On Tue, Oct 14, 2008 at 4:24 PM, James Antill <james@fedoraproject.org> wrote:
> But if you are going to ship a repo to end users which requires/uses
> the yum-priority plugin (or excludes, or whatever),

I am shipping a heavily "preconfigured" spin, the OLPC School Server.
It points to the standard F9 repos, plus OLPCXS repos. So far we
override... 1 package: ejabberd.

> then the simple
> advise I would give you is: _don't_.

Can you tell me a bit more about why? (I definitely respect your
technical advise, I'm trying to get more depth of info / experience on
this...)

As it's a single package and this could expand to a couple more
packages but no more, one alternative is to take that single package
and rename it ejabberd-xs and set it to provide:ejabberd,
conflicts:ejabberd.

I am already down that path with Moodle ("moodle-xs"), which I plan to
maintain as a long-term heavily customised package.

> Instead clone the Fedora repo. removing the packages you want to
> "override"

Quite a bit of work if I also want to give them access to sec updates
in a timely fashion :-) and my "conflict" with Fedora packages is
tiny.

> ... or even better get your changes into Fedora.

In some cases Fedora won't want them as they are strictly local
customisations -- such is the case of ejabberd and moodle. In others
Fedorans are looking into integrating changes in their own timeframes
(and I have my own release schedules to work for :-/ ).

It's a classic upstream/downstream game...

cheers,



m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 10-14-2008, 04:39 AM
James Antill
 
Default Tying yum to a package "stream"?

On Tue, 2008-10-14 at 16:48 +1300, Martin Langhoff wrote:
> On Tue, Oct 14, 2008 at 4:24 PM, James Antill <james@fedoraproject.org> wrote:
> > But if you are going to ship a repo to end users which requires/uses
> > the yum-priority plugin (or excludes, or whatever),
>
> I am shipping a heavily "preconfigured" spin, the OLPC School Server.
> It points to the standard F9 repos, plus OLPCXS repos. So far we
> override... 1 package: ejabberd.

Ok, that's kind of the worst case atm. ... I had assumed you'd be doing
this to a lot more.

> > then the simple
> > advise I would give you is: _don't_.
>
> Can you tell me a bit more about why? (I definitely respect your
> technical advise, I'm trying to get more depth of info / experience on
> this...)

There are two basic problems:

1. It's a lot less efficient to push the depsolving/repoclosure down to
each client, instead of solving it once on the server. So from that
point of view yum-priorities/etc. are _always_ going to give a worse
experience, even if we have all the data, make the depsolver a full SAT
solver while keeping it fast.

2. Fedora doesn't provide all of the data to make the above possible
anyway, so for instance F-9 might have foo-1.0-1 and then updates for
F-9 might release foo-1.0-2, foo-1.1-1, foo-1.2-1 ... by that point
_only_ foo-1.0-1 and foo-1.2-1 will be available (one pkg/version from
each repo.).
This means that if your repo. has bar-xo-1.0 requires "= foo-1.1" ...
all the old xo repos. now become broken you have to rush out a fixed
bar-xo and wait. You would still have "problems" if you did everything
server side, but you'd actually be able to run repoclose/etc. and see
the problem before it hit the clients ... and just not update your
cloned repo. until you fixed it, with yum-priorities the first you'll
see it is when all the clients don't work anymore.

> As it's a single package and this could expand to a couple more
> packages but no more, one alternative is to take that single package
> and rename it ejabberd-xs and set it to provide:ejabberd,
> conflicts:ejabberd.

This is a lot better, in that it totally solves #1 above. #2 still
applies (cross repo. deps. are the suck) although due to the rename
it'll be to a lesser extent than trying to override packages with higher
NEVRA.
Of course how much the cross repo. deps. problem hits you depends a lot
on the package, ejabberd doesn't look like it requires anything that
might be upgraded in a bad way ... and has no deps. on itself. So there
is a certain amount of "try it, it'll probably work fine".

> I am already down that path with Moodle ("moodle-xs"), which I plan to
> maintain as a long-term heavily customised package.
>
> > Instead clone the Fedora repo. removing the packages you want to
> > "override"
>
> Quite a bit of work if I also want to give them access to sec updates
> in a timely fashion :-) and my "conflict" with Fedora packages is
> tiny.

Yeh, I completely agree this is harder to do than it should be right
now ... as an end game it'd be nice if there was a way so you could just
publish a repo. which was "Fedora - <set of packages>" but all/most of
the package hosting was done via. the Fedora mirrors etc.

> > ... or even better get your changes into Fedora.
>
> In some cases Fedora won't want them as they are strictly local
> customisations -- such is the case of ejabberd and moodle. In others
> Fedorans are looking into integrating changes in their own timeframes
> (and I have my own release schedules to work for :-/ ).

Is there any way you could make the changes be basically bolt on
config. changes? so you have a ejabberd-config-xo or whatever? I'm
guessing you already looked at that, but I thought I'd ask...

> It's a classic upstream/downstream game...

Yeh, but think of it like Fedora vs. our upstream ... we copy all
the .tar.gz files locally, because we need to be isolated from changes
on their side. Ideally you'd do something similar to be isolated from
changes on our side, not being able to do that starts you on the road to
a bad place ... and yum-priorities is at the heart of the bad place .

--
James Antill <james@fedoraproject.org>
Fedora

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 10-14-2008, 05:06 AM
"Martin Langhoff"
 
Default Tying yum to a package "stream"?

Thanks a lot for your notes. *Extremely* useful. A few comments below,

On Tue, Oct 14, 2008 at 5:39 PM, James Antill <james@fedoraproject.org> wrote:
> On Tue, 2008-10-14 at 16:48 +1300, Martin Langhoff wrote:
>> I am shipping a heavily "preconfigured" spin, the OLPC School Server.
>> It points to the standard F9 repos, plus OLPCXS repos. So far we
>> override... 1 package: ejabberd.
>
> Ok, that's kind of the worst case atm. ... I had assumed you'd be doing
> this to a lot more.

Yes - it is the worst case, and I don't expect to see this grow significantly.

> There are two basic problems:
>
> 1. It's a lot less efficient to push the depsolving/repoclosure down to
> each client, instead of solving it once on the server. So from that
> point of view yum-priorities/etc. are _always_ going to give a worse
> experience, even if we have all the data, make the depsolver a full SAT
> solver while keeping it fast.

I did notice yum got a ton slower during the build once I added priorities.

> 2. Fedora doesn't provide all of the data to make the above possible
> anyway, so for instance F-9 might have foo-1.0-1 and then updates for
> F-9 might release foo-1.0-2, foo-1.1-1, foo-1.2-1 ... by that point
> _only_ foo-1.0-1 and foo-1.2-1 will be available (one pkg/version from
> each repo.).
> This means that if your repo. has bar-xo-1.0 requires "= foo-1.1" ...
> all the old xo repos. now become broken you have to rush out a fixed
> bar-xo and wait. You would still have "problems" if you did everything
> server side, but you'd actually be able to run repoclose/etc. and see
> the problem before it hit the clients ... and just not update your
> cloned repo. until you fixed it, with yum-priorities the first you'll
> see it is when all the clients don't work anymore.

Good point -- though with every custom package in the XS build I have
ample room to shoot myself in the foot with tight dependencies... with
or without priorities. True, getting fancy with tight interdeps
hjandled "transparently" via yum-priorities leads me in the wrong
direction...

>> As it's a single package and this could expand to a couple more
>> packages but no more, one alternative is to take that single package
>> and rename it ejabberd-xs and set it to provide:ejabberd,
>> conflicts:ejabberd.
>
> This is a lot better, in that it totally solves #1 above. #2 still
> applies (cross repo. deps. are the suck) although due to the rename
> it'll be to a lesser extent than trying to override packages with higher
> NEVRA.

Right - so we'll move to that model then and drop priorities. the
packages will look a tad funny, but it's ok.

We currently don't have any tight or tricky dependency, though our
repo is of course referring to stuff in fedora and
fedora-updates-newkey. Depending on php, httpd and python is not
something I stress about -- if fedora breaks any of them
significantly, I won't be alone in my anger... :-)

> Is there any way you could make the changes be basically bolt on
> config. changes? so you have a ejabberd-config-xo or whatever? I'm
> guessing you already looked at that, but I thought I'd ask...

Where we can, we do -- currently in a xs-config package that rolls
together lots of config overrides -- we'll break that down in due
course.

For ejabberd we have custom patches...

>> It's a classic upstream/downstream game...
>
> Yeh, but think of it like Fedora vs. our upstream ... we copy all
> the .tar.gz files locally, because we need to be isolated from changes
> on their side. Ideally you'd do something similar to be isolated from
> changes on our side, not being able to do that starts you on the road to
> a bad place ... and yum-priorities is at the heart of the bad place .

There are two ways to look at that. You keep complete control over the
deliverable, which is definitely saner but requires a ton more
development resources.

In the case of the XS, we are still in heavy develoment mode (though I
do cut releases, they are not a finished product). A lot is in motion
and with a tiny team. Just keeping abreast of "what fedora updates to
accept" in any useful way would swamp us.

So at this stage I can't hope to keep such complete control :-/ once
things stabilise at our end, I will review my options.

thanks again!


martin
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 10-14-2008, 05:16 AM
Mike McLean
 
Default Tying yum to a package "stream"?

Martin Langhoff wrote:

As it's a single package and this could expand to a couple more
packages but no more, one alternative is to take that single package
and rename it ejabberd-xs and set it to provide:ejabberd,
conflicts:ejabberd.


If you go this route, I think what you want is obsoletes. Obsoletes says
"this packages replaces this one." Conflicts says "this package cannot
be installed at the same time as this other one."


One mechanism gives the tools instruction on how to handle things, the
other is more of an assertion that mostly just causes the end user pain
when it comes up.


Building conflicts into your repositories is generally not very
friendly. Sometimes it may make sense, but I'm not sure it makes sense here.



I am already down that path with Moodle ("moodle-xs"), which I plan to
maintain as a long-term heavily customised package.


Instead clone the Fedora repo. removing the packages you want to
"override"


Quite a bit of work if I also want to give them access to sec updates
in a timely fashion :-) and my "conflict" with Fedora packages is
tiny.


I think you could come up with a reasonably fast sync script if you
wanted to go this way.


--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 10-14-2008, 05:49 AM
"Martin Langhoff"
 
Default Tying yum to a package "stream"?

On Tue, Oct 14, 2008 at 6:16 PM, Mike McLean <mikem@redhat.com> wrote:
> If you go this route, I think what you want is obsoletes. Obsoletes says
> "this packages replaces this one." Conflicts says "this package cannot be
> installed at the same time as this other one."

Does 'obsoletes' also mean "this package cannot be installed at the
same time as this other one."? Because things *will* go wrong if
someone installs moodle and moodle-xs :-/

>>> Instead clone the Fedora repo. removing the packages you want to
>>> "override"
>>
>> Quite a bit of work if I also want to give them access to sec updates
>> in a timely fashion :-) and my "conflict" with Fedora packages is
>> tiny.
>
> I think you could come up with a reasonably fast sync script if you wanted
> to go this way.

Sure - rsync to da rescue! :-) - but then there is no review and
testing, and we're back to the same situation as with pointing users
directly to the Fedora repos. Field installs may break if an update
comes through untested/unreviewed.

It makes sense to freeze our repo and selectively update it with
reviewed&tested updates from fedora... if you have the focus on
stability and the manpower to do it. Neither is true right now for me.

cheers,



m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
Old 10-14-2008, 11:52 AM
seth vidal
 
Default Tying yum to a package "stream"?

On Tue, 2008-10-14 at 18:49 +1300, Martin Langhoff wrote:
> On Tue, Oct 14, 2008 at 6:16 PM, Mike McLean <mikem@redhat.com> wrote:
> > If you go this route, I think what you want is obsoletes. Obsoletes says
> > "this packages replaces this one." Conflicts says "this package cannot be
> > installed at the same time as this other one."
>
> Does 'obsoletes' also mean "this package cannot be installed at the
> same time as this other one."? Because things *will* go wrong if
> someone installs moodle and moodle-xs :-/

You can obsolete and conflict

Obsoletes: pkgname=ver.rel
Conflicts: pkgname=ver.rel

-sv


--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 

Thread Tools




All times are GMT. The time now is 09:40 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org