ArchServer Project :: Forums

What is 'core' in AL is 'base' in AS. And what is 'base' and 'base-devel' in AL will be 'core' and 'core-devel' in AS. I didn't want to have a repo in AS and AL both called 'base' which could make it easy to accidentally "cross-pollinate" the two (eg, someone install AL then accidentally change their 'base' repo to an AS one). Of course when I changed the 'base' repo to 'core', this then got confusing when it came to the 'base' and 'base-devel' groups. So I figured the quickest solution to that was to change 'base' to 'core' in the groups...

This is still in a bit of a state of limbo I'm afraid... I missed changing the group in a lot of the PKGBUILD's when I was building everything, so I've had to go back and fix that, but I haven't had a chance to rebuilt everything again so some packages in the repo have the 'base' and 'base-devel' groups while the one's I've rebuilt have the proper 'core' and 'core-devel' groups. It will be fixed up as soon as I can rebuild the last of the packages -- hopefully this week before new years.

This isn't my ideal solution, as I realize the confusion it might create for those using both AL and AS, but it was the quickest solution I could think of to start getting some packages in to testing. I'm open to thoughts on other solutions moving forward?

Or maybe simply [server] and [server-devel] ?

+1 from my side as well.

Wanted to start a discussion on the mailing list as well. From my point of view, the naming of server-base is good.

The following is a list (from wikipedia) about the repositories of the archlinux project:

-- snip --
    * core, which contains all the packages needed to set up a base system
    * extra, which holds packages not required for the base system, including desktop environments and programs
    * testing, a special repository, with packages that are candidates for the core or extra repositories.
    * community, which contains packages built and voted on by the community; includes packages that have sufficient votes and have been adopted by a "trusted user".
    * community-testing, like the testing repository but for the packages that are candidates for the community repository.
-- snap--

So basically we are going to use then the following repositories with the mentioned meaning. What do you think?

    * server-base, contains all the packages needed to set up a core server system
    * lamp, holds packages for the LAMP, and also all derivates thereof (LAPP), systems
    * webapps, contains packages, which do provide web-applications
    * testing, a special repository, with packages that are candidates for all other.

So basically the question is now, if the server-base repository should contains also stuff like Ruby, Haskell, PHP??, and Java. Where does PHP really fit in? LAMP or server-base?

Should we probably provide different testing repositories for different main repositories (e.g. server-base-testing, lamp-testing)?

Furthermore, AL provides a couple of other repositories. Do we also need one of those (e.g. extras and later even community??)

    * extra, which holds packages not required for the base system, including desktop environments and programs
    * community, which contains packages built and voted on by the community; includes packages that have sufficient votes and have been adopted by a "trusted user".
    * community-testing, like the testing repository but for the packages that are candidates for the community repository.

So again, what do you think?

IMHO, we need probably a different testing repository for server-base (which i would prefer anyway), because this is gettting the biggest repository on our server, and therefor we could probably loose the overview, if we are not doing something like this. Also the extra repository could be worthwhile for packages not really belonging in server-base, but which are needed for a server anyway and probably even needed for applications in lamp and/or webapps.

-- added for clarification: ---
So for the server-extra, do think about packages like an IRC-Server or an Jabber-Server. Where do you put something like this right now, in server-base? In webapps?

Last edited by triplem (2010-Jan-07 08:34:31)

Do you mean to provide the e.g. lamp-repo inside the server-extra repo, but using a group to separate these packages?

You can just add packages to a group, just like AL does it now. For example, there is a group called base-devel inside core. base-devel is not a repository. When entering "pacman -Sy base-devel", pacman will install all packages in base-devel, even though they are in [core]. No need for a special repository, that's what the databases are for IMHO.

Edit: another example: add the line "groups=('lamp')" to apache, mysql and php. Now "pacman -Sy lamp" will install apache, mysql and php, regardless of the repository they are in.
What I'd like to see additionally are metapackages that include no files, but have dependencies and install-scripts themselves. That way it might be easier for users to create their own personal setups that can easily be deployed. I don't know if makepkg supports that right now, I never tried.

Last edited by IncredibleLaser (2010-Jan-07 11:43:45)

I personally see no reason to split the repositories, at least not for lamp. These are services like any other one that might go into extra. You say it yourself, shadowbranch. Why should a webserver be in another repository than a mailserver? Or a VoIP-Server? All of them provide internet services. Neither of them belong into core, though. The only internet service that belongs into core I can think of right now is ssh.

Ok, so I guess the structure would be:

base: core os packages
webapps: All applications that directly pertain to web usage(apache, lighttp, mysql, pgsql, phpmyadmin, dovecot, courier, postfix) all grouped for quick installation of certain sets
extra: other packages that do not fall into webapps(nfs, samba, java, ruby)
test: new packages not ready for live systems
community: other packages that have yet to make it into test

This seems like a simple layout of repos to me. Base gets us a barebones OS on our server for customization. Webapps will get us all our applications that are directly based towards the web. Java and Ruby do not fall in this category as they are not neccessarly directly for web use only. Extra can house other apps such as local network apps like LDAP, PHPLDAPAdmin, NFS, Samba and other such utilities. Test is of course for new packages that are either new releases of already repoed stable packages or packages that have been officially moved from the community portal. Community would be the collection of freely contributed PKGBUILDs for other packages.

How does that sound. I've tried to plain-text it all so there is a clear understanding of what is for what. I think a clear map out of what qualifies a package for what repo is what we need.

IncredibleLaser wrote:

First, we should clarify what repositories are there for.

100% right. But thats what ShadowBranch already tried to do, no?

IncredibleLaser wrote:

So my question is: Why another repository for webapps? I see no reason for (or against). It's more a matter of taste.

I am asking the same question. And to be honest, up until now, I thought, that webapps is a repository for real webapplications, e.g. for phpmyadmin, oscommerce, .... Thats why the definition is so important, so that everybody is on the same page. So the path you are suggesting is, first decide on the kind of repositories we need, and then on the name. I do think that this is the right way to go. At least from my point of view, I am not a fan of putting Stacks (software-stacks that is) into an own repository but in groups. Because otherwise you will run (sooner or later) into the same question we are asking right now: What belongs in this repository, and where to put the app XYZ????

Last edited by triplem (2010-Jan-07 16:55:02)

triplem wrote:

I thought, that webapps is a repository for real webapplications

Same thought here, webapps remind me of tools that users "see directly", like CMS, Web Panels or WebMails.
I understand the idea behind lamp, but I think we should take another name. I use LLPP (Linux Lighttpd PostGreSQL PHP), why should I use a repo named lamp ? Maybe something like services, and ruby/java/python falls into this category, as well as ejabber.

I prefer the simple approche of base/extras/community :
- It is familiar to AL users
- It is easier to figure where the problem will come from because everybody use base (lots of testing, quickly patched, keeped up-to-date by Trusted Users), many people use extras (not everybody rely on PHP, still many use it), and community is for more specific stuff (could possibly be out-of-date or unsafe).

However, we must change it to something else for compatibility with AL ! (while keeping the idea)

Meta-Package are powerful, letting the user install is webserver with pacman -S lamp seems like a good solution to me.

+1 for Option 2 except that I'd say server-core instead of server-base

Here is what I'd add to that though...

There are two things that I think are absolutely key when it comes to repos:

1.) Making sure that something in one doesn't depend upon something in another.
and most important
2.) Users aren't overly confused when trying to track down where a particular package is located.

Someone already hit the nail on the head when they said there are two different ways to handle repos, the Arch way (via groups of similar packages), and the Debian way (via levels of stability). The main thing that needs to be addressed is what purpose the repos will serve in AS.

First and foremost I think you need to maintain the AL way of doing things so as to cause minimal confusion when an AL users simply wants a "stable Arch server." Because in all honestly, that is probably why many people would use AS. They are familiar with AL, and like the methodology and way of thinking, they just want a stable release cycle. So I would try to keep the repos as "AL" like as possible, including names, without confusion (hence the "server-").

Then you could use groups inside the server-core/server-extra repos for specific common setups. Quite honestly, I think the main, if not only, difference between "extra" and "sever-extra" would be a stable release version. And the main, if not only, difference between "testing" and "server-testing" would be that the "server-testing" could be more of a Debian style repo (i.e. package stability separation).

Also, I do think the webapps repo has it mildly backwards. I wouldn't separate out packages because most server admins WANT those packages, I would separate out packages that most server admins DON'T want them. So they can selectively disable those sets of packages (be it X11 style packages, or what have you). So I would say the ONLY reason to make a whole new repo (and not just a group inside the repo) would be in case you have an entire group of packages that many server admins would not want on their servers, or could possibly cause harm to their servers. Because, that is actually the entire reason for ANY repo style, be it Arch or Debian style. You can selectively disable a repo so that you have no chance of drawing a package from that set of packages. There might be some very valid sets of packages you could do this to on a server distro. That way, if a server admin is sure he never wants access, or even a remote possibility of acquiring one of those packages, he can then disable the repo, in the same manner one would disable AL's testing repo for security or stability purposes.

Last edited by LoneStar (2010-Jan-07 21:35:04)

LoneStar wrote:

+1 for Option 2 except that I'd say server-core instead of server-base
1.) Making sure that something in one doesn't depend upon something in another.
and most important
2.) Users aren't overly confused when trying to track down where a particular package is located

+1 from me for the above mentioned statement.

Furthermore I would like to add, that all packages in the server-* (except probably testing for the above mentioned reasons) need to provide stable packages.

LoneStar wrote:

Also, I do think the webapps repo has it mildly backwards. I wouldn't separate out packages because most server admins WANT those packages, I would separate out packages that most server admins DON'T want them. So they can selectively disable those sets of packages (be it X11 style packages, or what have you). So I would say the ONLY reason to make a whole new repo (and not just a group inside the repo) would be in case you have an entire group of packages that many server admins would not want on their servers, or could possibly cause harm to their servers. Because, that is actually the entire reason for ANY repo style, be it Arch or Debian style. You can selectively disable a repo so that you have no chance of drawing a package from that set of packages. There might be some very valid sets of packages you could do this to on a server distro. That way, if a server admin is sure he never wants access, or even a remote possibility of acquiring one of those packages, he can then disable the repo, in the same manner one would disable AL's testing repo for security or stability purposes.

Could you please provide some examples here? I see your point, but would like to put some examples here, so that I and all the others see, where you are heading.