Arch Linux

>> Can't we have a INFO server?


Hmm, very interesting suggestion! I've never thought of that, but it may serve a great "middle-road" solution for everyone, assuming they have a functional network connection.

I don't have any free time to work on such a project. Perhaps another developer or community member could spearhead it?

IMO it is better to make separate packages:
package-x.y.z - binaries, configs and man pages
package-x.y.z-dev - include files, development libraries and man pages for library calls (for apache, php etc.)
package-x.y.z-doc - info files, HTML docs, readme files etc.

This sould not add much work for developers.
They should simply put different files in different packagres, instead of deleting info and HTML docs.

The same is for -dev packages - they are needed only when compiling some applications that require them. Most users don't need them.

And when developing this idea further:
ABS should be separated from pacman
This will make many base packages (gcc, make, autoconf etc.) not required but pacman.
Many users does not use ABS at all. So they don't need gcc and all related packages, and glibc and kernel headers are not needed too.
Of course, this would require some work and testing. But this packaging scheme would be really in the spirit of Arch.

As disk space is cheap, I don't really like the idea of -dev packages the debian way. You often end in having to install -dev packages additionally, same for the doc thing, just at the moment you need them. I don't want to be confronted with installing stuff while I work, it's just I have got that piece of software installed and I'm done. Also you will get 3x more packages which will make it difficult to have a useful pacman -Ss with weak keywords.. and so on. And on the package maintainer side, it's not as easy for the package builder to split the files as the easy going make install doesn't work for this...

If packages are split up I would recommend an automated solution and the possibility to declare globally if you wanted the -dev and -doc parts of packages installed automatically. So everyone can go for a minimal or "everything tied to this package I could need" setup. If he decides to stay minimal he would need something like pacman -S --dev <package> ..

Sorry for annoying you with my humble opinion.

Disk space is cheap is not a good argument. Then why just not install all packages available?
Think about upgrade process. Traffic is not cheap for most users. And manually adding NoUpgrade = gcc make autoconf etc. is not better than manually installing needed -dev packages.
IMO separating ABS from Pacman and making -dev and -doc packages is "What You Need Is What You Get".
That is not as complex as Gentoo's use flags. And there are much less packages in Arch than in Debian. And most packages will not have -dev, but only -doc.

About global setting of -dev and -doc stuff - nice idea, FoPref!
This could be implemented like this:

InstallDev = kernel26 glibc apache php mysql openssh openldap
InstallDoc = kernel26 coreutils apache php mysql
will install kernel26-dev, glibc-dev, ..., kernel26-doc, coreutils-doc, ...

InstallDev = * !kernel26
will install all -dev packages except kernel26-dev

Installing -dev packages is needed only for compiling something. So it's ABS job!
User will need to install -dev packages manually only if he/she wants to compile it's own packages that are not in official, AUR or other user's repository.
So I don't see the problem with -dev packages here.

As for -src packages:
kernel26 should include only binaries,
kernel26-dev - headers,
kernel26-src - full sources (should installing kernel26-src remove kernel26-dev from pacman database?)

You're right regarding the bandwidth, I have the same problem on my brother's machine but didn't think of it.
My main concerns are:
* don't seperate -dev, -doc branches completely from the main package, how it is done in debian. It should be clear that all the three things are part of the same

* I think one shouldn't install the kernel without it's headers

* I forgot that one :(


I don't know why you want to tie up -dev to ABS so much. I think most users who need -dev, don't need ABS at all and never checked it out. If someone want's to compile stuff, it's obviously most times stuff not available as package; but that doesn't mean he wants to make a package out of it, but first only he just wants to compile it. Even if you want to create your own package, do you need ABS for it? (should you need it?)

I think giving the user the need to have extra specific distro stuff (ABS and so on) simple to do a ./configure; make install (with dependancies) is not Arch philosophy. Or did I get it wrong?

You understand me slightly wrong.
In order to compile something user does not need ABS. User needs -dev packages to compile something that is dependent on headers that are in those -dev packages. And user needs -src packages in order to compile package from source. How is it done - with ABS or without it - it is user's choice.
When compiling something using ABS all -dev packages should be installed by ABS automatically.
When compiling manually - user should install required -dev packages manually or using InstallDev option in pacman.conf.

Why I should install kernel with headers when I use only binary packages and do not compile anything on my server?

Why do I need GCC and other stuff, glibc and kernel headers when I do not compile anything?
If I want to use ONLY binary packages on my server Pacman should allow me to do this easily.
Right now Pacman depends on GCC and other stuff because Pacman and ABS are in one package. Separating ABS from pacman fits perfectly in Arch philosophy.

Separating packages into subpackages is another thing.
IMO it is better to make separate packages:
package-x.y.z - binaries, configs and man pages
package-x.y.z-doc - info files, HTML files, READMEs, examples etc.
package-x.y.z-dev - include files, development libraries and man pages for library calls (for apache, php etc.)
package-x.y.z-src - full sources

Most packages will not have -dev subpackages at all. Many packages will not have -doc subpackages.
-src subpackages should contain not only sources, but also all patches that were used by package maintainer.

please don't seperate packages, this put more strain on package makers(me) and doesn't really serve a purpose other than playing nice with all the people with 10mb hdisks. Now, i only have a 16gb partition and i have lots of packages installed and it's only 40% full. The thing that you need to realise is that programs aren't the ones taking up harddisk space today. Music, movies and huge-games are the ones using up all the space. Now, since _atleast_ 90% of packages are programs, seperating packages in this way "complexifies" arch in a huge way, and where there's complexion there is room for much more error. This is true both from a package makers view but devastatingly more from a users perspective. You don't have to be terribly smart to see the horror scenarios this could create..

Now if you really want this Roman; switch to debian. I'm gonna shoot myself in the head.

if this gets implemented...

First of all, nut543, don't panic! :-)
Second, please take time to read all comments.
Thurd, I am not a Arch developer, so I can't do these changes. They are only proposals.

First and major proposal is to separate ABS from Pacman into another package.
This would eliminate Pacman's dependencies like GCC, make, autoconf etc.

Second group of proposals is about separating packages into subpackages.
Please try to understand that MOST packages will not require serious split!
-dev - MOST packages will not have this subpackage!
-src - that is simply a tarball of all sources AND patches that were used by package maker to make the package. Is this a big problem to make such -src package?
-doc - that is all those info files, HTML files, READMEs, examples etc. that are stripped when doing a package. Instead of stripping these docs from package developers would have to make them into another package. That is just replacing one stage of package making with another stage.
And the most important: -dev, -src, -doc will not require from package maker to make another PKGPBUILD or something else. These subpackages could be only tarballs!

And the last thing, specially for nut543:
I don't like Debian. And don't tell me which distro I should choose. If you gonna shoot yourself in the head - that is your right, but I'll don't want this to happen because my proposals to make Arch better (IMO) :-)

All those proposals is not intended to save space on someone's HDD. But, as a side effect, implementing these proposals will help users to save some bandwith (not very much though), which is important for users that have really small bandwith (for example 56K modem or GPRS connection).
These proposals are intended to make it easy for user to get what he/she wants. IMO that fits in The Arch Way.

To nut543: I'm sorry if my words were too emphasized. I was angry this morning. :-)
If at least ABS was separated from Pacman I would be happy. (I'm sure this could be easily done before Arch 0.8 release).
Separating packages into subpackages needs more work and if it will be implemented - would require more investigation of possible problems and more discussion. Anyway I doubt this will happen before Arch 0.9 or even before 1.0.

Yes, I'm adding a comment to an old feature request, I know, but meh. It's not _that_ old. :)

First off, to the original request (aka online automated info server) - THAT would be cool. Nerd points ++ if that ever gets implemented. :D

Secondly, onto Romashka's comments:

Splitting ABS and pacman? I could see this... not sure how terribly interwoven those two components are, but you'd think (in theory) that it wouldn't be that tough to do. Who knows, with libalpm coming (that _is_ its name, right?) perhaps this is part of that process and already underway? I should really subscribe to the dev/pacman mailing lists... I would probably find it terribly interesting to read.

Onto splitting packages:

-src package: IMO, creating seperate source packages would be a total waste of time. If you want the sources, use ABS or plain CVS to get the PKGBUILD and related files for the package you want, then run makepkg -o. Done. Everything for sources is currently readily available, and adding a -src package for every other package out there would just unnecessarily clutter the repos.

-doc packages: I suppose that could be automated by makepkg; I mean, it already removes all the docs, it probably wouldn't be too much effort to throw them in a package instead of rm'ing them. I personally wouldn't have much use for them, and discussion of stuff like info pages has been done to death already. I'd be more partial to the automated info server as mentioned above, myself... but then not everyone has 24/7 internet access from their Arch boxen.

-dev packages: One of the things I actually liked about Arch is that header files were included with the binary packages. As far as I can see, this really keeps things simple - "You want stuff for package foo? Then install package foo - it has all the stuff you need." as opposed to "Well, let's see. Are you just going to be running the program, or building other apps that depend on it? Or perhaps apps that depend on apps that depend on it? Well, in one case, only get foo, but in the other, get foo and foo-dev." - which one seems more KISS to you? :P

Anywho, them's my opinions. As always, take 'em the way I take my french fries - with multiple grains of salt. :D

About -src packages - you have the point. But IMHO it is more convenient to have all needed for compilation in one file than download sources from off.sites and patches and other files from CVS.

As for -dev packages - I disagree with you. Why should I download (and redownload during upgrade again and again) those files that I don't need. Especially when I use only binary packages, or when I'm not going to compile anything that depends on these packages. Keep in mind that not all people has fast and cheap Internet. But that is not the main argument.

As for installing foo vs. installing foo and foo-dev. Lets see this example:
I want to compile package A which requires headers from package B to compile. With current Pacman package management mekedepends=('B') in A PKGBUILD will require downloading and installing (!) package B and all packages that it requires!
For example, building Python with makepkg requires tk installed (because makedepends='tk') and tk requires tcl and libx11 (tk depends=('tcl' 'libx11')) and libx11 depends on the whole bunch of other packages. So to build Python I must have at least tk installed otherwise makepkg won't build Python. But Pacman -S tk wants to install many packages! (Yes, I know that I can force install without dependencies).
Is this KISS principle? I think no.
If there will be makedepends=('B-dev') then there will be no need to instal other packages with their requirements just to build package that depends on few headers from package B. In other words, I just need tk-dev to build python, and no other stuff. Is this KISS? I think yes.

So when there will be -dev subpackages you can install only what you want. If you want only binaries - you'll have them, without any headers or static libs; if you want to build something from source - you can do this, even easier than before.

Another good thing is IgnorePkg option in pacman.conf, but that is another feature request.

>>I want to compile package A which requires headers from package B to compile.
What's headers? Why do i need to know what headers are? Who understands what headers are except programmers?

>>So when there will be -dev subpackages you can install only what you want. If you want only binaries - you'll have them, without any headers or static libs; if you want to build something from source - you can do this, even easier than before.

What is -dev packages? Is it fair that i need to know how to seperate programs into -dev and "normal" when making packages when only people with slow connections will have a real use for this? If packages are split up like this i will get much more output when searching for a package and that might confuse me even more. "Do i need the -dev package?" , "what should i download?". See debian for all the problems this creates..

I think the question here really is; How many people share your situation Romashka? Should we impose more complexity on 95% of the users so that we can benefit those 5% of users who have no problem with -dev packages AND have a slow connection? One need to compromise here and see what would most people really want; and this is not even mentioning maintaining issues/slower rel schedule/more work for everyone ...

I'm going to try to keep this comment opinion-free; just making it to provide some data.

Just for kicks, I decided I wanted to find out what the proportion of header files to everything else on my system was. So, I wrote up the attached script.

Here's what I get from it:

$ ./calcHeaderSize.sh
Headers: 160.862M
Everything else: 7639.78M

As can be seen, the ratio of headers to everything else is pretty low, about 1-2% of all files in /opt and /usr, by space taken up on disk, are headers.

How about bandwidth? Well, I didn't feel like tarring up my entire system, but I did tar up all the header files that make up the 160.862M listed above:

$ du -s headers.tar.gz | awk '{print $1/1024}'
24.5947

So, since pacman distributes files in a .tar.gz format, I needed to download about 24.59M of data for these header files. Realistically, this number is higher, since I would have had to download certain headers many times with package upgrades.

Oh.. and I suppose one bit of "opinion": Romshaka said "Keep in mind that not all people has fast and cheap Internet." I know this. I'm one of the ones with cheap, but not-fast, internet. It takes me time to download stuff, but I don't mind terribly; I can just let it run in the background while I sleep. :P

For me the main problem is not even the size of unneeded stuff, but another thing: to build package with makedepends=('somepkg') I need to have 'somepkg' _installed_ and if not forced Pacman to skip dependencies - _with dependencies_ (but again, during upgrade Pacman wants to download all dependencies). Why makepkg won't just download required dependency, extract files and compile package that requires some files from it?

To nut543:

>> What's headers? Why do i need to know what headers are? Who understands what headers are except programmers?
You don't need to.

>> What is -dev packages?
pkgA-dev contains everything needed to build pkgB that has makedepends=('pkgA-dev') in its PKGBUILD.
-dev packages are not like real packages - they can be downloaded by makepkg, not only by pacman. They will be managed by pacman, but separately from main packages, so they .

>> Is it fair that i need to know how to seperate programs into -dev and "normal" when making packages when only people with slow connections will have a real use for this?
Not only with slow connections but also those who like to keep their systems clean and lean, without unneeded dependencies and their dependencies and their dependencies...
You don't need to know how to separate packages. This can be done _automatically_ by makepkg.
I repeat again - there will be not much packages that will require such split. Mainly - some libraries and dev tools, ie. kernel, glibc, gcc, apache, php, openldap, openssl etc.
>> If packages are split up like this i will get much more output when searching for a package and that might confuse me even more. "Do i need the -dev package?" , "what should i download?"
You will not have much more input. Pacman will show only non-dev packages by default. You will not have to download ANY -dev packages by hand in MOST situations, as they will be downloaded by makepkg.
Most users don't even need to know about existence of -dev packages!
>> See debian for all the problems this creates..
I've seen Debian. I've seen Red Hat too. But I haven't seen problems with -dev packages there. These are binary only distros. There are no ABS-like system, so -dev packages are needed mainly for programmers there. With ABS -dev packages has different reason to exist.

Please try to realize all that I said. I'm not going to impose this _idea_ on devs. They decide. I want just to explain my position and this idea. This is not so scare as some may think. And I have no power to implement this in Arch, as I'm not Arch developer. And _if_ this will be implemented - it anyway happens only in Arch 1.0 or later I suppose.

So, let's return to main topic. :-)
Would it be usefull if some packages had not only man, but also info and html docs?
I think some packages should have this inside (let's not talk about -info subpackages split, or we'll start another "to split, or not to split" debates. :-) ), for example - Apache, PHP, Python, Ruby, other programming languages.
Or do you think that user should go to official site and download documentation himself? And if so, should there be section on Arch website where this could be stored as proposed before - in easy searchable and downloadable form?

i'm not going to waste my time going point over point again; let the devs decide. I remember i thought just the fact that there were multiple packages for one application were very confusing when i were a linux noobie. The clue here i think is; make the system easy; don't try to abstract away the "difficult" parts when one could just have made the system easier in the first place thus not needing any abstraction at all.

saying MOST users won't need to know about dev packages at all is excactly the kind of attitute that eventually leads to Bad AbstractionTM IMO, and almost almost means that the user need to understand it anyway if they want control over their system. (whcich MOST do.)

anyway, i don't want to quibble..
abot info: a link to http://www.gnu.org/manual/manual.html on the main page would be helpful at the very least <;) maybe in the new redesign, if anything appears..

Well, there is at least one -doc package already: koffice-doc. :)
A link to GNU manual pages is very useful. Thanks, nut543!
Hmmm, maybe there could be pages generated with tools like info2html, man2html?

I know this thread is kind of old, and I know I didn't read all comments. I just want to leave here my comment: I think the overload of documentation or headerfiles in packages do not is sufficient to say it is a problem for those with low bandwidth. Also, I really do not like the idea of -dev packages (everytime I use a linux distro with those packages I end up having to install most of them to work and/or compile anything). Meanwhile, if you go ahead for -dev packages, documentation should be included on those (if it is for developers, developers need documentation).

Anyway, my feeling is that packages should be distributes as a whole. Things like bison info file are authentic books, and it is a crime not to include them.

Well, just my .05 euros.

Vote for seperate pacman and makepkg(ABS), but splitted package I quite doubt that.

Ugh. Ok. Final word here:

We don't distribute info pages. We just don't.

Anyone is welcome to make a repo that contains the info pages for packages. This is rather easy and can be scripted to updated along with out packages very very easily.

So here's the verdict: We're not going to do this. Anyone in the community is welcome to do it. The 'kdemod' guys seem to be the only ones who understand this fact.