You are not logged in.

#1 2004-11-23 18:36:22

Michel
Member
From: Belgium
Registered: 2004-07-31
Posts: 286

[idea] pacman config-files

Heya,

I was thinking about the following. It seems that people confifure their systems in different ways. Persons who are running servers, maybe need other settings than persons not running one, or people just want another point from which they start editing their configurations.

I read the posts that kde has some arch-customisations and I like it, although somewhere I would liek it also if this was an option.

So, I would like to propose to put the configuration-files of programs in a separate package. So, this people could contribute to configurations of programs, but the default ones are also available (maybe standard). So, this way we could change the default configurations for servers for example so they are maybe more secure than the default ones. This was what made me first think about this. Maybe we could try to get the configurations back upstream. Some may maybe argue that teh default ones should be good anyway. I agree with that but maybe some like one configuration while others like an other one, depending on your point of view. Maybe I'm wrong ...

Maybe there are other uses for, ... Maybe it makes things too complex. Maybe it's not needed.

I also now that an attractiev feature of PKGBUILD's is that they are simple nad I think that is a good idea.

I just would like to discuss the negatives and positives about this a little bit ...

Michel

Offline

#2 2004-11-23 18:39:07

Michel
Member
From: Belgium
Registered: 2004-07-31
Posts: 286

Re: [idea] pacman config-files

Heya,

just saw I posted this message three times (pressed the stop-button to make last-minute changes). Could anyone delete the 2 oldes t ones or the 2 other ones?

Sorry,

thanks

Offline

#3 2004-11-23 21:01:37

IceRAM
Member
From: Bucharest, Romania
Registered: 2004-03-04
Posts: 772
Website

Re: [idea] pacman config-files

Michel wrote:

Heya,

just saw I posted this message three times (pressed the stop-button to make last-minute changes). Could anyone delete the 2 oldes t ones or the 2 other ones?

Sorry,

thanks

I think you can delete them yourself (open them and choose "Delete").

On topic: adding default config files has been discussed before, but people agreed that it's better to have 'vanilla' packages. The package maintainers might be able to provide more info on this.

Offline

#4 2004-11-23 23:55:02

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

Re: [idea] pacman config-files

actually i like the idea because the "special" or "other" configs from the defaults that come with the package would be user contributed. i don't doubt that there are many times when a "special" configuration is actually more common than one would think. it also opens the door to any eventual multiarchitecture versions of arch that may appear (though i have yet to see any users actually finish what they say they want to do)


AKA uknowme

I am not your friend

Offline

#5 2004-12-09 10:37:48

Winkie
Member
Registered: 2004-09-30
Posts: 59

Re: [idea] pacman config-files

sarah31 wrote:

actually i like the idea because the "special" or "other" configs from the defaults that come with the package would be user contributed. i don't doubt that there are many times when a "special" configuration is actually more common than one would think. it also opens the door to any eventual multiarchitecture versions of arch that may appear (though i have yet to see any users actually finish what they say they want to do)

From my list of "Things I want to change about arch"
· Architecture flag, "arch=i686" would do fine in makepkg, perhaps the architecture name could be included in the package file name. Regardless this means alterations to pacman, makepkg and gensync.
· Base directory support, client configuration in pacman.conf, say for example, "basedir=/opt/packages/", pacman would then use that as the base for it's overlay, not / as is currently the standard. Requires modification of pacman only.
· Directory structure metadata. This would be a makepkg and pacman mod, the PKGBUILD would contain information about the layout of the final built tree, for example:

  bindir=/usr/bin
  confdir=/etc
  libdir=/usr/lib

Makepkg should be able to guess these on it's own, but it needs support for them in the PKGBUILD. This greatly increases the portability of packages, because if someone is running a non-standard system (See Arch's use of /etc/rc.d only where most distributions use /etc/init.d) this allows them to simply modify the pacman.conf at their end and change how the package is installed, again forcing all binaries, whether localbin (/usr/local/bin) or just bin (/usr/bin) into (/opt/packages/pkgname/bin) would be trivial with the 'Base directory support' mod above and this mod. It also means that specific sections of packages could be installed, for example, 'pacman -S postgresql:headers'.

Offline

#6 2004-12-09 17:03:13

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: [idea] pacman config-files

Winkie wrote:

From my list of "Things I want to change about arch"
· Architecture flag, "arch=i686" would do fine in makepkg, perhaps the architecture name could be included in the package file name. Regardless this means alterations to pacman, makepkg and gensync.
· Base directory support, client configuration in pacman.conf, say for example, "basedir=/opt/packages/", pacman would then use that as the base for it's overlay, not / as is currently the standard. Requires modification of pacman only.

a) would require doubling or tripling of the package server size - as all packages (think KDE, Xorg) would have to be compiled for all supported architectures.... kdelibs-i386, kdelibs-i586, kdelibs-i686, kdelibs-ppc... and so on

b) sounds decent, but this might start to get goofy... if a pacman package installs to /usr/local/bin.. you now end up with /opt/mystuff/somedir/usr/local/bin - why is this even an issue? disk space is disk space... why do people worry so much about organization....

Offline

#7 2004-12-09 17:14:42

Winkie
Member
Registered: 2004-09-30
Posts: 59

Re: [idea] pacman config-files

phrakture wrote:

a) would require doubling or tripling of the package server size - as all packages (think KDE, Xorg) would have to be compiled for all supported architectures.... kdelibs-i386, kdelibs-i586, kdelibs-i686, kdelibs-ppc... and so on

I was thinking more arch=ppc, but yes of course it would increase the size of the disk space neccasary... I don't see how this is a downside, multi-architecture binary package support pretty much implies it

phrakture wrote:

b) sounds decent, but this might start to get goofy... if a pacman package installs to /usr/local/bin.. you now end up with /opt/mystuff/somedir/usr/local/bin - why is this even an issue? disk space is disk space... why do people worry so much about organization....

What?! clearly you don't do sysadmin for a living. Do you put half your home directory files in /var/lib/ for the fun of it? Organisation is key, the most important thing is to offer users the CHOICE of where their packages go, not just say 'this package installs to /usr/bin/urmom', let them modify it and all will be happy.

Bear in mind that none of these things would require ANY change to the normal use of pacman / makepkg if they work as intended.

Offline

#8 2004-12-09 17:36:13

Dusty
Schwag Merchant
From: Medicine Hat, Alberta, Canada
Registered: 2004-01-18
Posts: 5,986
Website

Re: [idea] pacman config-files

Winkie wrote:
phrakture wrote:

a) would require doubling or tripling of the package server size - as all packages (think KDE, Xorg) would have to be compiled for all supported architectures.... kdelibs-i386, kdelibs-i586, kdelibs-i686, kdelibs-ppc... and so on

I was thinking more arch=ppc, but yes of course it would increase the size of the disk space neccasary... I don't see how this is a downside, multi-architecture binary package support pretty much implies it

I think I must have missed something in this discussion. As I understand it, when Arch goes multi-architecture, each architecture will get its own repository. That's why the repository names changed to os/i686 a while back.  What else are you suggesting?

phrakture wrote:

disk space is disk space... why do people worry so much about organization....

What?! clearly you don't do sysadmin for a living.

I have to agree, phrakture, that was one of your dumber statements. :-P

Organisation is key, the most important thing is to offer users the CHOICE of where their packages go, not just say 'this package installs to /usr/bin/urmom', let them modify it and all will be happy.

Could you provide a more specific example of what you're looking for here? If you just want to customize one or two packages, that's what PKGBUILD is for. If you want to customize every package... why?

Dusty

Offline

#9 2004-12-09 17:42:05

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: [idea] pacman config-files

Winkie wrote:

What?! clearly you don't do sysadmin for a living.

let's not start with broad generalizations and name calling, please.

The simple fact is this - things *are* organized, jut not the way *you* want them to be... pacman packages go to /usr...
If you start installing things to unknown locations, then you start ending up with conflicts... say for instance you have libfreetype.so installed in "/usr/lib/urmom[sic]/" - that would require changes to ld.conf, freetype .pc files, include paths, and many other things.  This is not a simple change upon installation... simplest case scenario, all pkg-config files would have some place holder for the base, along with a sed script every install.... this would have to be done for some config files as well...
Also, some packages (vim) have the base location for config files hardcoded in - the package would have to be recompiled to be relocatable on a system wide level.

The fact of the matter is this: Arch is based on simplicity.  This scheme with relocating entire installs upon installation is not simple.. it's very involved, and requires quite a bit on the part of the package maintainers to replace all scripts and PKGBUILDS with some relocatable placeholder... not to mention running numerois sed scripts and things of that nature upon install....
simplicty: download package, validity/sanity/conflict check, copy files (preserve path) to "/"
new scheme: download package, validity check, run sed scripts, confilct check, read base install dir, copy files (preserve path) to base install dir

Offline

#10 2004-12-09 17:42:42

i3839
Member
Registered: 2004-02-04
Posts: 1,185

Re: [idea] pacman config-files

Making a package for another architecture requires only a recompile and different gcc options which aren't set in the pkgbuild, but in makepkg.conf, so adding an option to makepkg isn't really needed. Pacman, makepkg and gensync don't need to change either, because makepkg is fine as it is, and pacman and gensync don't have to know about the architecture at all. To say which architecture you want you set the server vars in pacman.conf correctly (never noticed the "Server = ftp://ftp.archlinux.org/current/os/i686"?). So all the infrastructure is there already, only what's missing are the actual packages. If you use ccache then recompiling a package for another architecture after changing the cflags should take relatively short.

For idea two: Pacman -Sr perhaps?

-r, --root <path>   set an alternate installation root

Seems to do exactly what you want.

As for your third idea: it's very vague what you want, hardcoding the dir where the package will be installed? How can makepkg guess where the package should be installed while it's the package maker's choice? Sure, you can use a default, but other than that there's nothing to "guess".

Arch uses rc.d because it uses bsd init scripts instead of the ugly sysvinit stuff. Probably historical reasons why the one is named init.d and the other rc.d, but Arch isn't the only distro using rc.d.

The thing you seem to miss is that all those hardcoding of paths is done because most programs don't bother to be dynamic but simply hardcode at compile time where they can find all their stuff like config files. So simply installing them somewhere else than they expect will very often result in not working programs. And there isn't really a nice alternative to hardcoding the paths, because you always need some sort of config which can always be found. One of the few things you can do is use environment variables to tell the program where it can find it's config, but that causes a messy environment and /etc/profile.d/. And if most programs just use /etc anyway it isn't hard to see why that's hardcoded.

Allowing partial packages to be installed is asking for problems. If you want more fine grained control you should just split up the packages into smaller ones, which is much more work for the maintainers (thus not nice). Take a look at zeroinstall, perhaps you like it. Though nowaday people have such big harddisks that installing everything doesn't hurt, and partially downloading is no option because that would mean runtime splitting of packages, way too complicated, better to use a network filesystem, zerocopy or whatever then.

In reply to phrakture's comment:

Harddisk space is cheap, bandwidth isn't. So adding multiple versions of packages isn't really more expensive as people will only still download one version.

Without organisation your filesystem will become a real mess and no fun at all. You throw all simplicity and cleanness away, two major points of Arch. The good thing about organisation is that you can find things easily. But if people want to install standard packages in a non-standard place, then well, what's the sense of that? And if it are custom packages then they should go into the user's homedir or /usr/local/ (I use /opt too).

Offline

#11 2004-12-09 18:07:16

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: [idea] pacman config-files

oi! don't get me wrong - I'm not saying I want all my packages in a big old sloppy mess....
I'm saying that organization isn't black and white - it's not binary.... it's a sliding scale....
The people who dislike packages being installed to /usr/bin (what the directory exists for!) are a 10 out of 10 on the organization scale.  Arch is probably at about a 7 or so, mainly due to non-SysV init....and pacman maintaining most things.

Here's the thing... and I will use an analogy because most of us here will understand it.  Whenever you sit down to code, you have this idea that it will be this perfect looking code and it turns out that way just before the bugs start rolling in - then you throw an if statement here... some additional logic to make sure X is between 17 and 34... and some non transactional methods here and there.... organization is good, in theory, but reality doesn't work that way... 2nd law of thermodynamics - all systems tend toward chaos
You start with something and have this big ol' idea that it's going to be perfect... then things change - you can't nit-pick and worry this much about orgnaization... it's better to be able to adjust to an unorganized mess than to require orgnaization

what would happen if you were to get hired on a new sysadmin job and the previous admin deviced everything he installed went in /usr/local/custom or something or that nature... are you going to say "egads, it's not organized..."  and spend months moving binarys and libraries around after three or so years of installations?

Offline

#12 2004-12-09 19:27:55

Winkie
Member
Registered: 2004-09-30
Posts: 59

Re: [idea] pacman config-files

Woah, lot of replies, gimmie a minute:

Dusty wrote:

I think I must have missed something in this discussion. As I understand it, when Arch goes multi-architecture, each architecture will get its own repository. That's why the repository names changed to os/i686 a while back.  What else are you suggesting?

Nothing much really, it'd be nice to have some metadata in the package to define the architecture, so people don't attempt to install PPC packages on an i686 system, you know they will eventually sad

Could you provide a more specific example of what you're looking for here? If you just want to customize one or two packages, that's what PKGBUILD is for. If you want to customize every package... why?

What i'd like to see is some additional metadata in .FILEINFO, when makepkg builds the package, it can automatically guess that /usr/bin will be binaries, /usr/local/bin local binaries, /etc/ configuration files. If the metadata describes the package, you can alter the way it installs. I'll give a more complete description, we build a package with the following filestructure:

/usr
/usr/bin
/usr/bin/urmom
/usr/lib
/usr/lib/urmom.so
/etc
/etc/urmom
/etc/urmom/urmom.conf

makepkg would automatically enter this metadata into the .FILEINFO:

config=/etc/urmom
libraries=/usr/lib
binaries=/usr/bin

On the client side, if, for some reason, the person needed a specific package installing into a specific location, for example if all his configs were in /etc2/configs/, he would simply add configdir=/etc2/configs to his pacman.conf, when pacman extracts the packages, it will put the conf directory specified in the metadata into /etc2/configs instead of into /etc.

let's not start with broad generalizations and name calling, please

Apologies

The simple fact is this - things *are* organized, jut not the way *you* want them to be... pacman packages go to /usr...

I like this way of organisation, I have no problem with it, but it's nice to provide choice to the user

If you start installing things to unknown locations, then you start ending up with conflicts... say for instance you have libfreetype.so installed in "/usr/lib/urmom[sic]/" - that would require changes to ld.conf, freetype .pc files, include paths, and many other things. This is not a simple change upon installation...

The point of this mod would be to allow people with these non-standard configurations to install packages without issue. It would also help if pacman is ever used outside Arch linux, where, as my example said, /etc/rc.d didn't exist.

The fact of the matter is this: Arch is based on simplicity. This scheme with relocating entire installs upon installation is not simple.. it's very involved, and requires quite a bit on the part of the package maintainers to replace all scripts and PKGBUILDS with some relocatable placeholder...

That's the point, the idea is that you would have to make NO changes to any files, PKGBUILDs or anything, makepkg would try to automatically guess the locations and it would get a lot of them quite well. pacman would by default install the whole package to the default location, these options would be only if something non-standard was required. That's something i've kept in mind throughout.

Additionally, you have to point out your original point was a little silly.

For idea two: Pacman -Sr perhaps?

What the hell, when was that added? I missed it sad

Allowing partial packages to be installed is asking for problems.

Perhaps, again it would be an advanced option, never used unless neccasary, and no syntax changes.


Apologies for the abruptness before, I was at work and stressed yikes

Offline

#13 2004-12-09 20:02:49

Dusty
Schwag Merchant
From: Medicine Hat, Alberta, Canada
Registered: 2004-01-18
Posts: 5,986
Website

Re: [idea] pacman config-files

Winkie wrote:

Nothing much really, it'd be nice to have some metadata in the package to define the architecture, so people don't attempt to install PPC packages on an i686 system, you know they will eventually sad

I'm pretty sure this was discussed before, but I don't remember what the consensus was, if one was reached. I don't think Judd wanted to add yetAnotherVariable to the PKGBUILD, but there was more to it than that. As far as architecture goes, it wouldn't have to be the PKGBUILD that specifies it; makepkg could add it as meta-data all by itself.

Could you provide a more specific example of what you're looking for here? If you just want to customize one or two packages, that's what PKGBUILD is for. If you want to customize every package... why?

What i'd like to see is some additional metadata in .FILEINFO, when makepkg builds the package, it can automatically guess that /usr/bin will be binaries, /usr/local/bin local binaries, /etc/ configuration files. If the metadata describes the package, you can alter the way it installs.

I can't really imagine this being useful, but if you wanted to write a patch that does this stuff, Judd might accept it. Or you could release it separately. Its one of those functionality vs simplicity tradeoffs, I think.

The point of this mod would be to allow people with these non-standard configurations to install packages without issue. It would also help if pacman is ever used outside Arch linux, where, as my example said, /etc/rc.d didn't exist.

Pacman is already used outside of Arch, I've heard (sorry no link). However, in such a case, I don't imagine you would use Arch packages; you'd have to develop packages specific to the distro that it was being used on, I think.  You can't share packages across distros, be it RPM (horrid example), pacman, slack, or apt unless the distros use the same fileset.

makepkg would try to automatically guess the locations and it would get a lot of them quite well.

What happens with the one it doesn't get. Doing stuff automagically is generally in complete conflict with simplicity... it makes things easier on the average, but when things break, you don't know what to do. This is why I like Arch. I have to do everything myself, so I know what's been done.

Out of curiosity, do you have a specific project you are working on that requires this functionality in pacman, or is it just a hypothetical scenario?

Dusty

Offline

#14 2004-12-09 20:19:15

Winkie
Member
Registered: 2004-09-30
Posts: 59

Re: [idea] pacman config-files

Dusty wrote:

I'm pretty sure this was discussed before, but I don't remember what the consensus was, if one was reached. I don't think Judd wanted to add yetAnotherVariable to the PKGBUILD, but there was more to it than that. As far as architecture goes, it wouldn't have to be the PKGBUILD that specifies it; makepkg could add it as meta-data all by itself.

Yep, guessing it would be simple and it would work beautifully.

I can't really imagine this being useful, but if you wanted to write a patch that does this stuff, Judd might accept it. Or you could release it separately. Its one of those functionality vs simplicity tradeoffs, I think.

The thing is, it wouldn't require any lack of simplicity. By default you wouldn't have the definitions in the PKGBUILD or the pacman.conf, and pacman would work as normal, you'd only notice it if you actually needed it.  I am working on these though in my own spare time.

You can't share packages across distros, be it RPM (horrid example), pacman, slack, or apt unless the distros use the same fileset.

You can as long as certain library versions match.

What happens with the one it doesn't get. Doing stuff automagically is generally in complete conflict with simplicity... it makes things easier on the average, but when things break, you don't know what to do. This is why I like Arch. I have to do everything myself, so I know what's been done.

Then the data would have to be added manually, if at all. The point is that you would only ever know about these things if you needed them, you could still type 'pacman -S pkgname' as default and you would never need to add variables to your PKGBUILD because even if makepkg only gets 5/10, then that's still 5 sections created with about 30 bytes overhead and no loss of simplicity, but added functionality.

Out of curiosity, do you have a specific project you are working on that requires this functionality in pacman, or is it just a hypothetical scenario?

I'm going to be using Arch to power my place of employment, and i'll be developing (when I have time) and patching programs where I find that I need them, i'm going to be adding a few more things not listed to pacman/gensync etc to help with managing 40 client machines against 2 internal repositories (time-lagged). I'll explain more fully if you're interested, but i've got virtually no code so I figured it'd be a little early to say anything.

Offline

#15 2004-12-09 20:44:00

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: [idea] pacman config-files

Winkie wrote:

I'm going to be using Arch to power my place of employment, and i'll be developing (when I have time) and patching programs where I find that I need them, i'm going to be adding a few more things not listed to pacman/gensync etc to help with managing 40 client machines against 2 internal repositories (time-lagged). I'll explain more fully if you're interested, but i've got virtually no code so I figured it'd be a little early to say anything.

oi! this issue has been discussed to death... not knocking you Winkie, it just comes up alot... "I'm installing arch on 50 machines at work, can you change progam X to fit my needs".  While I can understand that this could have its uses in normal user cases, it is more geared toward the business world....

Offline

#16 2004-12-09 21:08:17

Dusty
Schwag Merchant
From: Medicine Hat, Alberta, Canada
Registered: 2004-01-18
Posts: 5,986
Website

Re: [idea] pacman config-files

phrakture wrote:

oi! this issue has been discussed to death... not knocking you Winkie, it just comes up alot... "I'm installing arch on 50 machines at work, can you change progam X to fit my needs".

Winkie is saying "I'm installing arch on 50 machines and I'm changing program X to fit my needs". Big difference there.   Whether the changes get accepted into mainstream pacman is a different story, and a moot point until we see some code.

If it doesn't get accepted into pacman, this might finally end the 'discussed to death discussion' because it could provide a base for developing further 'business world' adaptations... perhaps a new distro, perhaps as an addendum to Arch.

Nothing is lost by doing it... but you're right about one thing, it doesn't need any more discussion. wink

Dusty

Offline

#17 2004-12-12 04:59:40

Xentac
Forum Fellow
From: Victoria, BC
Registered: 2003-01-17
Posts: 1,797
Website

Re: [idea] pacman config-files

Well, even though Dusty says things don't need to be discussed more, I'll add my two cents.

From the top:

- Just moving around files in an already compiled package won't work in some cases because of the hard coded (at compile time) paths, as phrakture pointed out with examples like vim and freetype.  It's better just to compile the package with your own modifications instead of trying to bend an already compiled package to your will.  You might want to look into srcpac.

- I did bring up the architecture-in-the-filename point once to the developers.  One particular developer didn't like the idea because it broke backwards compatibility (which is a big issue, granted), none of the other developers mentioned anything.  I believe it's still on the meeting agenda.
(Note for Dusty, adding another field to the .PKGINFO isn't a big deal at all  and I don't think Judd minds doing it, as long as it's warrented)

- If you have 50 machines and want a few packages configured a certain way, my suggestion is to make an internal repo.  As long as you put it above the [current] entry in /etc/pacman.conf packages in it will be installed instead of those in current and extra (that's how we make testing work).  That way pacman stays simple, you get the power of most of arch, and can keep your changes across many machines without pulling your hair out.


I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal

Offline

#18 2004-12-13 09:33:16

Winkie
Member
Registered: 2004-09-30
Posts: 59

Re: [idea] pacman config-files

Xentac wrote:

- Just moving around files in an already compiled package won't work in some cases because of the hard coded (at compile time) paths, as phrakture pointed out with examples like vim and freetype.  It's better just to compile the package with your own modifications instead of trying to bend an already compiled package to your will.  You might want to look into srcpac.

Yes I know about compile time stuff.. Again my point is stated above, whilst some files are required to stay in the same location, some are not.

- If you have 50 machines and want a few packages configured a certain way, my suggestion is to make an internal repo.  As long as you put it above the [current] entry in /etc/pacman.conf packages in it will be installed instead of those in current and extra (that's how we make testing work).  That way pacman stays simple, you get the power of most of arch, and can keep your changes across many machines without pulling your hair out.

Beat you to it ages ago.

[root@nec1 isher]# ls
chmlib        gpasman-dev  javamail  net-snmp     pisg      rsnapshot
fileschanged  help2man     libevent  nss_ldap     postfix   wxmozilla
glurp         jaf          logwatch  openxchange  rapidsvn  xchm
gmpc          jailkit      mpd       pam_ldap     rrdtool

Offline

Board footer

Powered by FluxBB