Re: Base distro + Requirements definition



sön 2002-06-23 klockan 16.54 skrev Jeff Waugh:
> <quote who="Mikael Hallendal">
> 
> > Me and Bevin is currently designing a package system which will be based
> > on Gentoo's Portage but will be much improved compared to it.
> > 
> > There have been discussions about what to use for base, either Debian or
> > Gentoo. Though I believe that we should use this new package system (which
> > will hold of the start of packaging a while, shouldn't be too much of a
> > problem since there are lot of designing to do before that).
> > 
> > .debs is a (imho) mess to work with and Gentoo's portage doesn't fulfill
> > all of the requirements. By doing the package system together with this
> > project also gives us the possibility to make sure that the package system
> > / tools can be used in the ways we want.
> 
> Ugh. This topic.
> 
> Well, my perspective is this: Nothing that exists fits the bill, but nothing
> we make will be worth the work.
> 
> We all have our favourites... Much as I like GAR, it's inappropriate because
> it builds from source. That's not a useful feature for either users or
> administrators of desktop operating systems, and will get in the way of
> solving the problem. I put Gentoo in the same category.

Gentoo _does_ support full-binary distribution. The binary support is
not that good though, this will be greatly improved by Bagheera (which
will have a APT-like binary support but with the source support of
Gentoo).

> Much as I like Debian, the packaging tools are a pain. The format is not so
> bad, but actually making them is more work than it should be.

Since lots of work goes into fixing packages to our liking I think it's
very important that we use something where maintaining the packages is
not a PITA. I don't think that we can assume that we will be able to use
the .debs as is if we want to take this the entire way (which we want).

> I'd like to think RPM is a good start, but I don't think the "stock
> standard" Red Hat base system is a good idea. Other systems have done things
> more elegantly. That said, the packaging format is simple, and there's a
> large enough support base out there to make our job easier.

RPM's is imho better. It's a nicer package system to work with, and
since I don't think we will be able to use the packages out-of-the-box
anyway I think that we should choose with respect with what will be the
easiest way to manipulate the packages/add new ones.

> So, for all my internal arguing, I've come back to Debian. Sure, the tools
> for packaging are not so great - perhaps we can do something about that in
> time - but at the end of the day, there is an awesome infrastructure there,
> and I don't think we should be reinventing the wheel. Especially wheels that
> Debian has solved so well, and have people working on all the time.
> 
> The biggest bang for buck will come from:
> 
>   - infrastructural elegance

Which elegance? :)

>   - work already done for us, and not having to redo any of it

I don't think we can assume we won't have to change anything from a
stock Debian. Now I haven't used Debian for about a year but I used it
for about 5 years before that.

There were _lots_ of things that I found that I had to do myself that is
done for me in for example Red Hat. 

The way we would have to go would be further if we were using Debian
than Red Hat. Using Bagheera would be even further _but_ we get the
freedom of having a system where we can do pretty much what we want (as
long as it's reasonable). Also, the main port of the Bagheera work will
be done by Bevin (who is not primary interested in the GNOME OS project
and will develop Bagheera even if we will not choose to use it for GNOME
OS).

Trying to get the Debian dev. team to accept doing changes for our sake
is probably next to important. Using Bagheera we will be somewhat
dependent that others will help maintaining the base packages (which I
think will not be a problem, there are already two other distributions
thinking about using it, one meta distr. ala Gentoo/Debian, and one
similar to ours).

>   - people working on stuff that may not be in our direct interest (fixing
>     bugs in X, etc)

We get this stuff anyway, without having the people on our team doing
the actual fixing.

>   - a give and take upstream community, which we can contribute to and
>     benefit from

While this is nice it can also be a problem since we are going to be the
on-the-side distribution that has to workaround there decisions instead
of taking part of them.
 
> I'm not convinced that other distributions have the unique balance of
> talent, sheer manpower, well-designed infrastructure and basic usability
> that Debian does. I think it's our best bet out of a not-necessarily-
> brilliant bunch.

Sure, Debian does probably have the most manpower, but imho it's badly
used since I don't think that there development model maximize use of
the manpower at hand. I'm pretty sure you could have 40 developers do
about the same work as the 800 (or something) developers of Debian (and
this is not full time working developers).

In Gentoo when I was around there we were about 10 and sure we were
doing a lot of work but we were developing a distribution from scratch,
not just maintaining one (without any progress, as it seems anyway).

> > So, I would say that the first step is to decide on target group, then
> > make a list of requirements. After that we can start to design the system
> > to fulfill those reqs.
> 
> I think that the basic, networked corporate desktop is a good start, and
> after that, x-terminal and network integration features, and additional
> features for a home desktop.

I would agree that the networked corporate desktop would be _very_
interesting solution to strive for. Though it's much more work than for
the home user. Would be very interesting though and I would definitely
like to aim for this. 

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal                micke codefactory se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918




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