[arch-dev-public] The core of Arch Linux - repo reorganization - Arch-dev-public

newer
[arch-dev-public] missing packages...

[arch-dev-public] The core of Arch Linux - repo reorganization

Pierre Schmitz

10 Jul 2007 10 Jul '07

4:38 p.m.

Hi all, reading the last dev meeting log I realized that we need a clean concept to organize our package repositories. The problem: We have two official repositories: [current] and [extra]. Historically [current] should fit on a cd-r and includes packages preferred by Judd (and maybe some other "early" devs). [extra] should include everything else. Today nobody really know why a package is in current or extra. In addition to this we have some dependencies from current into extra and some non-free packages in current. This makes distribution on a cd/dvd quite difficult. Any last but not least: There is no easy way to install packages from a cd after the system is set up. So I do not think we need to worry about cd-r size. The solution: Imho the only solution is to drop those repos and set up new ones with a clear definition what should be included. This is only a fist proposal. A concrete package list has to be worked out later. [core] This repo will include those packages which have to be installed on every arch system regardless if its a server, workstation or notebook. This category will be similar (but not the same) as the current base category. It should contain all packages that are needed for a basic installation and it should be able to connect to the internet. (including all networking modules, ssh etc.) Furthermore it must include all tools and libs that are needed to rebuild and maintain the repo. So we need gcc, abs, csup, devtools etc. in [core] [core] should have some stricter policy when someone wants to update, add or delete packages. Major updates should pass a set of tests first. Minor and security updates could pass immediately. Addition or Deleting of packages should be discussed on ml before. And of course this repo should not depend on anything else (including makedepends) [extra] Everything else (like xorg, KDE etc.) will go into a "new" [extra] repo. This will be like the extra repo we currently have. But I would recommend the following policies: * only include "stable" software (meaning no alpha, beta, svn, git etc. branches). We should use [unstable] for those. * packages which are only used by very few users might be moved to [community] (see package cleanup) [non-free] As mentioned above it would be a good idea to move all non-free packages to a separate repo. This way we wouldn`t have any problems with distributing core+extra on a dvd. Of course no other package from any other repo should depend on one from non-free. [testing] and [unstable] are special and imho they don`t need further discussion. ;-) Step by step: 1) decide which packages should be in the [core] repo (check dependencies etc.) 2) move everything else into extra 3) cleanup extra; move packages into non-free, community or even aur 4) make sure there are no broken dependencies (including makedepends). It should look like this: [core] <- [extra] ^----------^----[non-free] ^----------^----[unstable] ^----------^----[community] Ok this is only a first proof of concept and a lot of work has to be done; bu what do you think of this idea? Pierre -- archlinux.de

Show replies by date

Thomas Bächler

10 Jul 10 Jul

4:59 p.m.

Pierre Schmitz schrieb:

...

Hi all,

reading the last dev meeting log I realized that we need a clean concept to organize our package repositories.

The problem:

[...]

The solution:

Imho the only solution is to drop those repos and set up new ones with a clear definition what should be included. This is only a fist proposal. A concrete package list has to be worked out later.

[core] [extra] [non-free] [testing] and [unstable] are special and imho they don`t need further discussion. ;-)

First of all (as already stated in the meeting), I would support such a scheme.

...

Step by step:

1) decide which packages should be in the [core] repo (check dependencies etc.)

That is sort of decided by the scheme you proposed. Our current base category, openssh and a new "drivers" category with all drivers that are 1) freely distributable and 2) necessary to bring networking up and running. And we may have to add some filesystem tools. In the proposed scheme, cored shouldn't be much more. A "core" cd would then replace our base installation cd.

...

2) move everything else into extra 3) cleanup extra; move packages into non-free, community or even aur

Agreed. Depending on usage, importance and man-power decisions, things should be either in extra or community. Note that the distinction between extra and community is made obvious by the separation of the dev group and the tu group. Packages maintained by TUs go to community, packages maintained by devs to extra. The core+extra repos would make an archlinux dvd, which could replace our current "full" iso. It could be made available to offline users, so archlinux would be more offline/dialup friendly - we'd have to keep up our regular snapshots though.

...

4) make sure there are no broken dependencies (including makedepends). It should look like this: [core] <- [extra] ^----------^----[non-free] ^----------^----[unstable] ^----------^----[community]

Note that this cannot always be strict with makedepends. For example, mplayer (extra) would have a non-free makedepend (codecs). But it should be kept strict for depends.

...

Ok this is only a first proof of concept and a lot of work has to be done; bu what do you think of this idea?

I was one of the people pushing this scheme on the meeting. My main reason was that there would be a clean definition of our repositories, while there is no such thing for current and extra right now. The idea has my support.

Dan McGee

8:47 p.m.

On 7/10/07, Pierre Schmitz wrote:

...

The problem:

We have two official repositories: [current] and [extra]. Historically [current] should fit on a cd-r and includes packages preferred by Judd (and maybe some other "early" devs). [extra] should include everything else.

Today nobody really know why a package is in current or extra. In addition to this we have some dependencies from current into extra and some non-free packages in current. This makes distribution on a cd/dvd quite difficult.

Any last but not least: There is no easy way to install packages from a cd after the system is set up. So I do not think we need to worry about cd-r size.

The only worry is whether [core] from below can fit- if that is ever a problem, then we have bigger problems. :)

...

The solution:

Imho the only solution is to drop those repos and set up new ones with a clear definition what should be included. This is only a fist proposal. A concrete package list has to be worked out later.

<snip>

...

Step by step:

1) decide which packages should be in the [core] repo (check dependencies etc.) 2) move everything else into extra 3) cleanup extra; move packages into non-free, community or even aur 4) make sure there are no broken dependencies (including makedepends). It should look like this: [core] <- [extra] ^----------^----[non-free] ^----------^----[unstable] ^----------^----[community]

Ok this is only a first proof of concept and a lot of work has to be done; bu what do you think of this idea?

The above idea seems very logical. I do worry about extra getting a bit large, but we can do something about splitting that later. My only concern rests with the strict dependency tree. I agree that no package in core should depend or makedepend on anything outside of that repo. However, I feel like packages in the other repos could makedepend (but NOT depend) on repos below them in the hierarchy as long as it is clearly noted in the PKGBUILD. This is similar to what Thomas said in his reply. +1 -Dan

Roman Kyrylych

19 Jul 19 Jul

10:13 a.m.

2007/7/11, Dan McGee :

...

On 7/10/07, Pierre Schmitz wrote:

...
The problem:

We have two official repositories: [current] and [extra]. Historically [current] should fit on a cd-r and includes packages preferred by Judd (and maybe some other "early" devs). [extra] should include everything else.

Today nobody really know why a package is in current or extra. In addition to this we have some dependencies from current into extra and some non-free packages in current. This makes distribution on a cd/dvd quite difficult.

Any last but not least: There is no easy way to install packages from a cd after the system is set up. So I do not think we need to worry about cd-r size.

The only worry is whether [core] from below can fit- if that is ever a problem, then we have bigger problems. :)

...
The solution:

Imho the only solution is to drop those repos and set up new ones with a clear definition what should be included. This is only a fist proposal. A concrete package list has to be worked out later.

<snip>

...
Step by step:

1) decide which packages should be in the [core] repo (check dependencies etc.) 2) move everything else into extra 3) cleanup extra; move packages into non-free, community or even aur 4) make sure there are no broken dependencies (including makedepends). It should look like this: [core] <- [extra] ^----------^----[non-free] ^----------^----[unstable] ^----------^----[community]

Ok this is only a first proof of concept and a lot of work has to be done; bu what do you think of this idea?

The above idea seems very logical. I do worry about extra getting a bit large, but we can do something about splitting that later. My only concern rests with the strict dependency tree. I agree that no package in core should depend or makedepend on anything outside of that repo. However, I feel like packages in the other repos could makedepend (but NOT depend) on repos below them in the hierarchy as long as it is clearly noted in the PKGBUILD. This is similar to what Thomas said in his reply.

+1

-Dan

I'm reading all important post-devmeeting threads now (that I've intentionally left unread to concentrate on quick small less important threads first), finally cleaning my mailbox. I'm not impressed that we have 3 threads about repo reorganisation now. So, here's my +1 for Pierre's summary + Thomas' correction about makedepends. I remember this scheme circulating in discussions since March and I'm very satisfied with it. And -1 for Paul's scheme. -- Roman Kyrylych (Роман Кирилич)

Damir Perisa

10:59 a.m.

New subject: [arch-dev-public] why?

hi all, i was just reading this suggestion by Pierre and i can follow all the thoughts. here the comments from my side: * i strongly agree, that the decision if something is in current or extra should be made after some rules. this rules actually existed earlier... kind of between devs (we were not so much as nowadays) but unfortunately, i cannot find a list with this rules ;) the thing is: earlier it was only some devs working on current... i till now do not have (and do not need) write access to current. since all my pkgs are not system-related and all in extra. of course the more people are involved, the bigger something gets, the better should be de rules written down... this we need to solve first ... before or instead of trying to revolutionise things ;) * nothing in current can depend on anything in extra or another repo. this was one of this rules. if we have now such situations, either we have to move the deps to current or we trow the pkg causing the conflict out of current. * if something is not freely distributable by archlinux, then we should not have it at all in an official repo! i cannot think of anything to fall into this category... but i'm not aware of all the pkgs we have in the repos... if something is not freely distributable by us and is in the repos, please point to it - we should stop distributing it or find an agreement with the authors. * i strongly disagree to put pkgs in to repos according to their licence! licence management should be happening in pacman or by an external tool keeping track of this things. the only exception is that if we are not allowed to distribute something, we should not. but then, this thing should be in no repo at all! * why renaming the current repo? current and extra make perfectly sense in the KISS approach to me. greetings, damir -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

Aaron Griffin

1:02 p.m.

New subject: [arch-dev-public] why?

On 7/19/07, Damir Perisa wrote:

...

* why renaming the current repo? current and extra make perfectly sense in the KISS approach to me.

My biggest problem is grammar. "current" and "extra" don't follow each other. "less" and "more", "east" and "west", "monday" and "saturday" - all these words are related in some way. "current" and "extra" don't make any sense? If "current" is current, does that mean extra is not current? Is current more up to date than current? "extra" what? More extra than "current"? Does that mean it's from the future?

Dale Blount

1:13 p.m.

New subject: [arch-dev-public] why?

On Thu, 2007-07-19 at 14:02 -0500, Aaron Griffin wrote:

...

On 7/19/07, Damir Perisa wrote:

...
* why renaming the current repo? current and extra make perfectly sense in the KISS approach to me.

My biggest problem is grammar. "current" and "extra" don't follow each other. "less" and "more", "east" and "west", "monday" and "saturday" - all these words are related in some way.

"current" and "extra" don't make any sense? If "current" is current, does that mean extra is not current? Is current more up to date than current? "extra" what? More extra than "current"? Does that mean it's from the future?

[base] and [extra] make much more sense to me. Especially when you get into the fact that we tag packages in [current] with CURRENT and packages in [extra] are also tagged CURRENT. Man, I was a confused dev when that first happened. Dale

Damir Perisa

1:45 p.m.

New subject: [arch-dev-public] why?

Thursday 19 July 2007, Dale Blount wrote: | On Thu, 2007-07-19 at 14:02 -0500, Aaron Griffin wrote: | > On 7/19/07, Damir Perisa wrote: | > > * why renaming the current repo? current and extra make | > > perfectly sense in the KISS approach to me. | > | > My biggest problem is grammar. "current" and "extra" don't | > follow each other. "less" and "more", "east" and "west", | > "monday" and "saturday" - all these words are related in some | > way. | > | > "current" and "extra" don't make any sense? If "current" is | > current, does that mean extra is not current? Is current more up | > to date than current? "extra" what? More extra than "current"? | > Does that mean it's from the future? | | [base] and [extra] make much more sense to me. Especially when | you get into the fact that we tag packages in [current] with | CURRENT and packages in [extra] are also tagged CURRENT. Man, I | was a confused dev when that first happened. true - you both of you are right. the naming was not linguistically correct in the beginnning. but it worked for years *smile* if we change the name, "base" makes more sense as do "core". "core" or -- introducing another name -- "nucleus" would be everything from the base category we have now + some other pkgs? if there is really a mature reason to rename a repository, then go for it... but be aware that this would break backwards compatibility becasue on all the cd's and installers till now (ftp install especially), we have the naming hardcoded. actually, thinking forward-projected, it would be not too bad, if the installer if trying to use any online-repositories (compared to offline install-media provided repositories) would first synch a information-file what archlinux offers for stuff atm. - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

6160

Age (days ago)

6169

Last active (days ago)

List overview

Download

7 comments

7 participants

participants (7)

Aaron Griffin
Dale Blount
Damir Perisa
Dan McGee
Pierre Schmitz
Roman Kyrylych
Thomas Bächler