[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fwd: Fedora & openSUSE meeting / cooperation ?]

On 2/6/07, Thorsten Leemhuis <fedora leemhuis info> wrote:
I think the answer should be: as upstream maintainer get involved or at
least in contact with the distributions. That's why I'd like to see
upstream maintainers as co-maintainers in Fedora if possible.

<dreaming>Another possible solution: all (important) software agrees to
use a similar, time based release scheme. E.g. everyone releases a
stable version twice a year (March and September) and applies only
bugfixes to the stable versions, while the devel stuff gets into the
devel repo. The distributions could then push the updates to the stable
distribution and the devel version to their devel tree, that gets a
release in April and October. In other words: let the whole world aligns
to the gnome release model and its foreseeable schedule</dreaming>

Both of those are equally dreamy. The whole point of what opensuse is
trying to do is make it so that people can do it once, distribute it
over a large number of platforms. Having the maintainer of the package
also be a co-maintainer in every distribution they want to distribute
something through is insane, and just the kind of totally bullshit
hoops that we must eliminate if we actually want linux to become a
first-class platform.

[This is only true if your vision of the future of Linux includes
multiple distros; if your vision is that there is only the One True
Distro, then yes, having upstream also be co-maintainers in the One
True Distro makes sense. This is basically Canonical's vision. In some
ways it makes sense- we gain a lot of efficiencies by having One True
Kernel which everyone else forks from; why not have One True Distro
that everyone else forks from. Of course, putting it in the hands of a
proprietary tool makes me get violent.]

On 2/6/07, Christopher Blizzard <blizzard redhat com> wrote:
> And I tend to think: that's not possible (or very very hard). The
> software packages in our distribution often has heavy
> inter-dependencies. So if you update one, then chances are high to break
> something else. Just take Firefox (galeon, liferia, yelp, several more
> use exactly the firefox version for which it was build), or gaim (some
> plugins like otr, libnotify) for example (there are a lot more), that
> are used by several other packages.

It's hard, sure.  Isn't this also what Ximian used to do before they
were eaten by the giant N?  I remember a discussion of a database driven
app that would create your spec files on the fly, etc, no matter what
you were using.  Not sure how it worked, either.  I guess Luis can relay
some of that if he chooses.

It was the only way to do what we did, so we didn't have much choice
in the matter. Implementation details aren't all that important, but
basically it had a sort of meta-spec file and worked its way down from
there roughly as you describe. I'd imagine opensuse's build farm does
something similar, though AFAIK the two tools do not share any code or
even common developers.

It was of course wildly popular, because it solved exactly the problem
we're discussing here, which is a very real problem for users.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]