[pacman-dev] [abs] Proto files and Makeworld

newer
[pacman-dev] translation procedure

Travis Willard

4 Jan 2008 4 Jan '08

3:11 p.m.

Hey guys, With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged. To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself. The proto files (PKGBUILD.proto, install.proto, and possibly a ChangeLog.proto?) seem to belong with makepkg in my mind. Any changes in these proto files would be directly caused by changes to makepkg, and the coupling of putting them in with the pacman package seems to make sense. I've never understood why we sync them with abs in the first place - if someone wants a prototype PKGBUILD to start from, why should they have to download the entirety of our repos' build scripts? In short, I think we should move makeworld to the abs project/package, and move the prototype files into the pacman project/package, perhaps in /usr/share/pacman/*proto? Thoughts? -- Travis

Attachments:

attachment.html (text/html — 1006 bytes)

Show replies by date

Xavier

4 Jan 4 Jan

3:27 p.m.

Travis Willard wrote:

...

Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

The proto files (PKGBUILD.proto, install.proto, and possibly a ChangeLog.proto?) seem to belong with makepkg in my mind. Any changes in these proto files would be directly caused by changes to makepkg, and the coupling of putting them in with the pacman package seems to make sense. I've never understood why we sync them with abs in the first place - if someone wants a prototype PKGBUILD to start from, why should they have to download the entirety of our repos' build scripts?

In short, I think we should move makeworld to the abs project/package, and move the prototype files into the pacman project/package, perhaps in /usr/share/pacman/*proto?

Thoughts?

Both suggestions makes sense in my opinion too. I didn't like the current location of the proto files, I don't know what they are doing in core/. And you are right, it would probably fit better with makepkg than with all the others PKGBUILDs. So I like your proposal.

Dan McGee

4:52 p.m.

On Jan 4, 2008 9:11 AM, Travis Willard wrote:

...

Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Big +1 here. I have been slowly but surely trying to eliminate the hard links to ABS in the pacman source, and this is (as far as I know) the last one, although we could generalize it. I can offer assistance here getting it moved over and cleaned up (remove the gettext stuff?) if you want, as I've already had to do this with the abs script.

...

The proto files (PKGBUILD.proto, install.proto, and possibly a ChangeLog.proto?) seem to belong with makepkg in my mind. Any changes in these proto files would be directly caused by changes to makepkg, and the coupling of putting them in with the pacman package seems to make sense. I've never understood why we sync them with abs in the first place - if someone wants a prototype PKGBUILD to start from, why should they have to download the entirety of our repos' build scripts?

Original decisions die hard :). Take a glance at contrib/ in the pacman source- there you will find PKGBUILD.proto and proto.install, which should always be the canonical definition. I think it would be very wise for us to install these with the pacman package somewhere in /usr/share, and maybe have some symlinks for old times sake in the abs package from /var/abs/. Note to self: look into where those files should live in the pacman-git repo (probably should be somewhere besides contrib as they should be installed by default).

...

In short, I think we should move makeworld to the abs project/package, and move the prototype files into the pacman project/package, perhaps in /usr/share/pacman/*proto?

Thoughts?

Good to see you already taking charge. Thanks! -Dan

eliott

5:48 p.m.

...

On Jan 4, 2008 9:11 AM, Travis Willard wrote: Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Sounds good to me too. On 1/4/08, Dan McGee wrote:

...

Original decisions die hard :). Take a glance at contrib/ in the pacman source- there you will find PKGBUILD.proto and proto.install, which should always be the canonical definition. I think it would be very wise for us to install these with the pacman package somewhere in /usr/share, and maybe have some symlinks for old times sake in the abs package from /var/abs/.

I don't think we even need to symlink them. If we just provide a README in the /var/abs/ root with high level information about abs, we could slap a 'proto files are located in /usr/share....' or wherever.

Dan McGee

5:56 p.m.

On Jan 4, 2008 11:48 AM, eliott wrote:

...

...
On Jan 4, 2008 9:11 AM, Travis Willard wrote: Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Sounds good to me too.

On 1/4/08, Dan McGee wrote:

...
Original decisions die hard :). Take a glance at contrib/ in the pacman source- there you will find PKGBUILD.proto and proto.install, which should always be the canonical definition. I think it would be very wise for us to install these with the pacman package somewhere in /usr/share, and maybe have some symlinks for old times sake in the abs package from /var/abs/.

I don't think we even need to symlink them. If we just provide a README in the /var/abs/ root with high level information about abs, we could slap a 'proto files are located in /usr/share....' or wherever.

cat > /var/abs/README << EOF ABS is a collection of the PKGBUILDs used to make your Arch Linux packages. It is also a good starting place to learn how to make your own. If you want a clean prototype, then please see the prototype PKGBUILD and install file shipped with pacman & makepkg, located in /usr/share/pacman/. EOF -Dan

Travis Willard

6 p.m.

On Jan 4, 2008 12:56 PM, Dan McGee wrote:

...

On Jan 4, 2008 11:48 AM, eliott wrote:

...
...
On Jan 4, 2008 9:11 AM, Travis Willard wrote: Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Sounds good to me too.

On 1/4/08, Dan McGee wrote:

...
Original decisions die hard :). Take a glance at contrib/ in the pacman source- there you will find PKGBUILD.proto and proto.install, which should always be the canonical definition. I think it would be very wise for us to install these with the pacman package somewhere in /usr/share, and maybe have some symlinks for old times sake in the abs package from /var/abs/.

I don't think we even need to symlink them. If we just provide a README in the /var/abs/ root with high level information about abs, we could slap a 'proto files are located in /usr/share....' or wherever.

cat > /var/abs/README << EOF ABS is a collection of the PKGBUILDs used to make your Arch Linux packages. It is also a good starting place to learn how to make your own. If you want a clean prototype, then please see the prototype PKGBUILD and install file shipped with pacman & makepkg, located in /usr/share/pacman/. EOF

+1 - sounds fine by me. I'll add the necessary readme to the package... when I make the package. :P I think we should offer a ChangeLog.proto too, in an attempt to help standardize our changelog format. Something like as was mentioned in a semi-recent email thread... that I can't find. I've got it bookmarked at home, but it was something like: date * pkgname-pkgver-pkgrel Reason we changed stuff Another reason we changed stuff gcc-4.1.patch: Removed, no longer needed and so on.

Xavier

6:12 p.m.

Travis Willard wrote:

...

+1 - sounds fine by me. I'll add the necessary readme to the package... when I make the package. :P

I think we should offer a ChangeLog.proto too, in an attempt to help standardize our changelog format. Something like as was mentioned in a semi-recent email thread... that I can't find. I've got it bookmarked at home, but it was something like:

date

* pkgname-pkgver-pkgrel Reason we changed stuff Another reason we changed stuff gcc-4.1.patch: Removed, no longer needed

and so on.

Aaron just gave the link yesterday :) http://archlinux.org/pipermail/arch-dev-public/2008-January/004020.html Your example looks fine though. Just two unimportant comments : - the packager name is missing - I wanted to make it explicit that the file should end with just one newline. Some ChangeLog don't even have one newline, so pacman needs to add one manually. And then the other ChangeLog that already had two newlines (== one empty line at the end) end up with two empty lines, which doesn't look very nice.

Travis Willard

6 p.m.

On Jan 4, 2008 11:52 AM, Dan McGee wrote:

...

...
Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and

On Jan 4, 2008 9:11 AM, Travis Willard wrote: the

...
.proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Big +1 here. I have been slowly but surely trying to eliminate the hard links to ABS in the pacman source, and this is (as far as I know) the last one, although we could generalize it. I can offer assistance here getting it moved over and cleaned up (remove the gettext stuff?) if you want, as I've already had to do this with the abs script.

Any help you could offer for that would be appreciated.

Aaron Griffin

6:01 p.m.

On Jan 4, 2008 10:52 AM, Dan McGee wrote:

...

On Jan 4, 2008 9:11 AM, Travis Willard wrote:

...
Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Big +1 here. I have been slowly but surely trying to eliminate the hard links to ABS in the pacman source, and this is (as far as I know) the last one, although we could generalize it. I can offer assistance here getting it moved over and cleaned up (remove the gettext stuff?) if you want, as I've already had to do this with the abs script.

Agreed. Feel free to pull it into the abs tree whenever you want. Just let us know so we can kill it off from the pacman codebase.

...

...
The proto files (PKGBUILD.proto, install.proto, and possibly a ChangeLog.proto?) seem to belong with makepkg in my mind. Any changes in these proto files would be directly caused by changes to makepkg, and the coupling of putting them in with the pacman package seems to make sense. I've never understood why we sync them with abs in the first place - if someone wants a prototype PKGBUILD to start from, why should they have to download the entirety of our repos' build scripts?

Original decisions die hard :). Take a glance at contrib/ in the pacman source- there you will find PKGBUILD.proto and proto.install, which should always be the canonical definition. I think it would be very wise for us to install these with the pacman package somewhere in /usr/share, and maybe have some symlinks for old times sake in the abs package from /var/abs/.

I agree that these should be in /usr/share/pacman/. We should also keep them in the ABS tree for the time being.

...

Note to self: look into where those files should live in the pacman-git repo (probably should be somewhere besides contrib as they should be installed by default).

...
In short, I think we should move makeworld to the abs project/package, and move the prototype files into the pacman project/package, perhaps in /usr/share/pacman/*proto?

Thoughts?

Good to see you already taking charge. Thanks!

-Dan

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

Eric Belanger

6:29 p.m.

On Fri, 4 Jan 2008, Aaron Griffin wrote:

...

On Jan 4, 2008 10:52 AM, Dan McGee wrote:

...
On Jan 4, 2008 9:11 AM, Travis Willard wrote:

...
Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Big +1 here. I have been slowly but surely trying to eliminate the hard links to ABS in the pacman source, and this is (as far as I know) the last one, although we could generalize it. I can offer assistance here getting it moved over and cleaned up (remove the gettext stuff?) if you want, as I've already had to do this with the abs script.

Agreed. Feel free to pull it into the abs tree whenever you want. Just let us know so we can kill it off from the pacman codebase.

...
...
The proto files (PKGBUILD.proto, install.proto, and possibly a ChangeLog.proto?) seem to belong with makepkg in my mind. Any changes in these proto files would be directly caused by changes to makepkg, and the coupling of putting them in with the pacman package seems to make sense. I've never understood why we sync them with abs in the first place - if someone wants a prototype PKGBUILD to start from, why should they have to download the entirety of our repos' build scripts?

Original decisions die hard :). Take a glance at contrib/ in the pacman source- there you will find PKGBUILD.proto and proto.install, which should always be the canonical definition. I think it would be very wise for us to install these with the pacman package somewhere in /usr/share, and maybe have some symlinks for old times sake in the abs package from /var/abs/.

I agree that these should be in /usr/share/pacman/. We should also keep them in the ABS tree for the time being.

The community abs tree (/var/abs/community) has some proto files for SCM PKGBUILDs and rc script. Perhaps we should put all these proto files in one location (/var/abs or /usr/share)

...

...
Note to self: look into where those files should live in the pacman-git repo (probably should be somewhere besides contrib as they should be installed by default).

...
In short, I think we should move makeworld to the abs project/package, and move the prototype files into the pacman project/package, perhaps in /usr/share/pacman/*proto?

Thoughts?

Good to see you already taking charge. Thanks!

-Dan

-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Aaron Griffin

6:52 p.m.

On Jan 4, 2008 12:29 PM, Eric Belanger wrote:

...

The community abs tree (/var/abs/community) has some proto files for SCM PKGBUILDs and rc script. Perhaps we should put all these proto files in one location (/var/abs or /usr/share)

Great idea. How about this: * We take all these proto files that are deemed "useful" and stick them in the abs tree. This might end up being like 10 or so. * The abs package installs them all to /usr/share/abs or /usr/share/pacman/prototypes or something * We post a mini-announcement about this, for completeness Additionally, I said "lets just keep them in the abs CVS for right now" but after talking to cactus, I'd say - if everyone is fine with "spreading the word" here, we can kill those off two - I am impartial, I was just leaning towards the less work / less confusion route.

Xavier

7:03 p.m.

Aaron Griffin wrote:

...

Additionally, I said "lets just keep them in the abs CVS for right now" but after talking to cactus, I'd say - if everyone is fine with "spreading the word" here, we can kill those off two - I am impartial, I was just leaning towards the less work / less confusion route.

I personally find the current locations (in core/ and in community/) very confusing. So removing them from there would result in less confusion for me :)

Travis Willard

7:06 p.m.

On Jan 4, 2008 1:52 PM, Aaron Griffin wrote:

...

* The abs package installs them all to /usr/share/abs or /usr/share/pacman/prototypes or something

IMO they belong in the pacman package, since their content is tightly coupled with any changes made to makepkg. Otherwise, I agree - /usr/share/pacman/prototypes is a good place for them.

Dan McGee

7:14 p.m.

On Jan 4, 2008 1:06 PM, Travis Willard wrote:

...

On Jan 4, 2008 1:52 PM, Aaron Griffin wrote:

...
* The abs package installs them all to /usr/share/abs or /usr/share/pacman/prototypes or something

IMO they belong in the pacman package, since their content is tightly coupled with any changes made to makepkg. Otherwise, I agree - /usr/share/pacman/prototypes is a good place for them.

Wow, a small issue is becoming a hot topic here. :) My thoughts: 1. PKGBUILD.proto, ChangeLog.proto, and proto.install belong in the pacman package. Thus they also belong in /usr/share/pacman. 2. Everything else (SCM PKGBUILD templates, etc) is sugar on the cake. Those should be part of abs. For consistency's sake, it is probably best to put them in /usr/share/pacman. I doubt the FHS looks highly upon mucking with the /usr/share/ directory of another program, so these should probably *not* be in /usr/share/pacman/. However, this is a homebrew package, specific to Arch, so not such a big deal. (Alternative: just keep these in abs, and with a switch to rsync we could drop them wherever we wanted them in /var/abs). I believe what I outlined above works well with both Aaron's suggestion and Travis' thoughts. The stock prototype files definitely belong in the pacman data directories. -Dan

Travis Willard

7:16 p.m.

On Jan 4, 2008 2:14 PM, Dan McGee wrote:

...

Wow, a small issue is becoming a hot topic here. :)

I only talk about hot topics. First the logo contest, now the location of proto files. I gotta be careful whenever I open my mouth, lest I start another fire. :D

...

My thoughts: 1. PKGBUILD.proto, ChangeLog.proto, and proto.install belong in the pacman package. Thus they also belong in /usr/share/pacman. 2. Everything else (SCM PKGBUILD templates, etc) is sugar on the cake. Those should be part of abs. For consistency's sake, it is probably best to put them in /usr/share/pacman. I doubt the FHS looks highly upon mucking with the /usr/share/ directory of another program, so these should probably *not* be in /usr/share/pacman/. However, this is a homebrew package, specific to Arch, so not such a big deal. (Alternative: just keep these in abs, and with a switch to rsync we could drop them wherever we wanted them in /var/abs).

I believe what I outlined above works well with both Aaron's suggestion and Travis' thoughts. The stock prototype files definitely belong in the pacman data directories.

Fine by me.

Aaron Griffin

7:33 p.m.

On Jan 4, 2008 1:14 PM, Dan McGee wrote:

...

Wow, a small issue is becoming a hot topic here. :)

My fault: I misunderstood the intent here. I thought we wanted to move ALL the proto files to abs, and I ran with it. But yes, obviously it makes sense to keep the BASE set of them in pacman. Call me a fool. I have a quick, unrelated comment, though.

...

I doubt the FHS looks highly upon mucking with the /usr/share/ directory of another program, so these should probably *not* be in /usr/share/pacman/.

Actually, the only thing the FHS mentions is "if you're putting data in /usr/share, use a subdir, please. Here's some good ideas" It's fairly common to "muck with" directories in this manner. Take, for instance /usr/share/terminfo, /usr/share/mime-info, /usr/share/applications, /usr/share/icons, etc etc.

Dan McGee

6 Jan 6 Jan

5:08 p.m.

On Jan 4, 2008 9:11 AM, Travis Willard wrote:

...

Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Done...hope I didn't steal your thunder here. See the current abs.git repo (I promise I'll try not to touch it anymore! haha).

...

The proto files (PKGBUILD.proto, install.proto, and possibly a ChangeLog.proto?) seem to belong with makepkg in my mind. Any changes in these proto files would be directly caused by changes to makepkg, and the coupling of putting them in with the pacman package seems to make sense. I've never understood why we sync them with abs in the first place - if someone wants a prototype PKGBUILD to start from, why should they have to download the entirety of our repos' build scripts?

And also done. They now live in the top level of the pacman repository, and they are installed (at least on Arch) to /usr/share/pacman/. -Dan

Travis Willard

5:23 p.m.

On Jan 6, 2008 12:08 PM, Dan McGee wrote:

...

On Jan 4, 2008 9:11 AM, Travis Willard wrote:

...
Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Done...hope I didn't steal your thunder here. See the current abs.git repo (I promise I'll try not to touch it anymore! haha).

Onoz! I am less a man - Dan hath touched mine sacred ABS project. Heh - thanks for moving that over.

...

...
The proto files (PKGBUILD.proto, install.proto, and possibly a ChangeLog.proto?) seem to belong with makepkg in my mind. Any changes in these proto files would be directly caused by changes to makepkg, and the coupling of putting them in with the pacman package seems to make sense. I've never understood why we sync them with abs in the first place - if someone wants a prototype PKGBUILD to start from, why should they have to download the entirety of our repos' build scripts?

And also done. They now live in the top level of the pacman repository, and they are installed (at least on Arch) to /usr/share/pacman/.

I'll do the same with the "non-standard" prototypes and throw them in the same location in the abs package... when I make the ABS package, that is. OH - I'm going to need core access, and I'll either need to bug eliott to add an rsync stanza for ABS, or get the permissions to add it myself, so I can test out this new rsync-style ABS and get it working up to snuff. How were we generating the tree for that again? Commit/tag hooks? Something in the db-repo scripts? And, for that matter, where would be a good place to locate the generated ABS tree server-side? /var/abs?

eliott

7:31 p.m.

On 1/6/08, Travis Willard wrote:

...

On Jan 6, 2008 12:08 PM, Dan McGee wrote:

...
On Jan 4, 2008 9:11 AM, Travis Willard wrote:

...
Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Done...hope I didn't steal your thunder here. See the current abs.git repo (I promise I'll try not to touch it anymore! haha).

Onoz! I am less a man - Dan hath touched mine sacred ABS project.

Heh - thanks for moving that over.

...
...
The proto files (PKGBUILD.proto, install.proto, and possibly a ChangeLog.proto?) seem to belong with makepkg in my mind. Any changes in these proto files would be directly caused by changes to makepkg, and the coupling of putting them in with the pacman package seems to make sense. I've never understood why we sync them with abs in the first place - if someone wants a prototype PKGBUILD to start from, why should they have to download the entirety of our repos' build scripts?

And also done. They now live in the top level of the pacman repository, and they are installed (at least on Arch) to /usr/share/pacman/.

I'll do the same with the "non-standard" prototypes and throw them in the same location in the abs package... when I make the ABS package, that is.

OH - I'm going to need core access, and I'll either need to bug eliott to add an rsync stanza for ABS, or get the permissions to add it myself, so I can test out this new rsync-style ABS and get it working up to snuff.

Just let me know what you want added, and I will add it. This is what I had for testing at one point. [abstest] hosts allow = <myip> path = <dir in my home dir> comment = abs test 4 eliott list = false exclude = CVS read only = true #refuse options = c compress #dont compress = * I was fiddling with the compression options. Compression adds alot of cpu overhead, and turning it off (forcing it off) yeilded much better server side load reduction. However, it used a bit more bandwidth... *shrug*

...

How were we generating the tree for that again? Commit/tag hooks? Something in the db-repo scripts? And, for that matter, where would be a good place to locate the generated ABS tree server-side? /var/abs?

In my testing I was using a cronjob that updated the tree periodically. Not sure how it should be done in the long run... As to dir location on gerolde, not sure. I think abs lives in /home/abs/ right now.

Dan McGee

9:24 p.m.

On Jan 6, 2008 1:31 PM, eliott wrote:

...

On 1/6/08, Travis Willard wrote:

...
On Jan 6, 2008 12:08 PM, Dan McGee wrote:

...
On Jan 4, 2008 9:11 AM, Travis Willard wrote:

...
Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Done...hope I didn't steal your thunder here. See the current abs.git repo (I promise I'll try not to touch it anymore! haha).

Onoz! I am less a man - Dan hath touched mine sacred ABS project.

Heh - thanks for moving that over.

...
...
The proto files (PKGBUILD.proto, install.proto, and possibly a ChangeLog.proto?) seem to belong with makepkg in my mind. Any changes in these proto files would be directly caused by changes to makepkg, and the coupling of putting them in with the pacman package seems to make sense. I've never understood why we sync them with abs in the first place - if someone wants a prototype PKGBUILD to start from, why should they have to download the entirety of our repos' build scripts?

And also done. They now live in the top level of the pacman repository, and they are installed (at least on Arch) to /usr/share/pacman/.

I'll do the same with the "non-standard" prototypes and throw them in the same location in the abs package... when I make the ABS package, that is.

OH - I'm going to need core access, and I'll either need to bug eliott to add an rsync stanza for ABS, or get the permissions to add it myself, so I can test out this new rsync-style ABS and get it working up to snuff.

Just let me know what you want added, and I will add it. This is what I had for testing at one point.

[abstest] hosts allow = <myip> path = <dir in my home dir> comment = abs test 4 eliott list = false exclude = CVS read only = true #refuse options = c compress #dont compress = *

I was fiddling with the compression options. Compression adds alot of cpu overhead, and turning it off (forcing it off) yeilded much better server side load reduction. However, it used a bit more bandwidth... *shrug*

...
How were we generating the tree for that again? Commit/tag hooks? Something in the db-repo scripts? And, for that matter, where would be a good place to locate the generated ABS tree server-side? /var/abs?

In my testing I was using a cronjob that updated the tree periodically. Not sure how it should be done in the long run...

As to dir location on gerolde, not sure. I think abs lives in /home/abs/ right now.

/srv/abs_rsync ? -Dan

eliott

10:53 p.m.

On 1/6/08, Dan McGee wrote:

...

On Jan 6, 2008 1:31 PM, eliott wrote:

...
On 1/6/08, Travis Willard wrote:

...
On Jan 6, 2008 12:08 PM, Dan McGee wrote:

...
On Jan 4, 2008 9:11 AM, Travis Willard wrote:

...
Hey guys,

With ABS splitting off from pacman, I was wondering where makeworld and the .proto files belonged.

To me, makeworld seems to be an abs tool (and even mentions ABS in its usage) so it would seem to belong in the abs project, not with pacman itself.

Done...hope I didn't steal your thunder here. See the current abs.git repo (I promise I'll try not to touch it anymore! haha).

Onoz! I am less a man - Dan hath touched mine sacred ABS project.

Heh - thanks for moving that over.

...
...
The proto files (PKGBUILD.proto, install.proto, and possibly a ChangeLog.proto?) seem to belong with makepkg in my mind. Any changes in these proto files would be directly caused by changes to makepkg, and the coupling of putting them in with the pacman package seems to make sense. I've never understood why we sync them with abs in the first place - if someone wants a prototype PKGBUILD to start from, why should they have to download the entirety of our repos' build scripts?

And also done. They now live in the top level of the pacman repository, and they are installed (at least on Arch) to /usr/share/pacman/.

I'll do the same with the "non-standard" prototypes and throw them in the same location in the abs package... when I make the ABS package, that is.

OH - I'm going to need core access, and I'll either need to bug eliott to add an rsync stanza for ABS, or get the permissions to add it myself, so I can test out this new rsync-style ABS and get it working up to snuff.

Just let me know what you want added, and I will add it. This is what I had for testing at one point.

[abstest] hosts allow = <myip> path = <dir in my home dir> comment = abs test 4 eliott list = false exclude = CVS read only = true #refuse options = c compress #dont compress = *

I was fiddling with the compression options. Compression adds alot of cpu overhead, and turning it off (forcing it off) yeilded much better server side load reduction. However, it used a bit more bandwidth... *shrug*

...
How were we generating the tree for that again? Commit/tag hooks? Something in the db-repo scripts? And, for that matter, where would be a good place to locate the generated ABS tree server-side? /var/abs?

In my testing I was using a cronjob that updated the tree periodically. Not sure how it should be done in the long run...

As to dir location on gerolde, not sure. I think abs lives in /home/abs/ right now.

/srv/abs_rsync ?

Keep in mind that with the way gerolde is setup, /home has lots of space, while some of the other mount points do not. :/ Do a df -h to see what i mean.

Aaron Griffin

7 Jan 7 Jan

4:56 p.m.

On Jan 6, 2008 4:53 PM, eliott wrote:

...

Keep in mind that with the way gerolde is setup, /home has lots of space, while some of the other mount points do not. :/

Do a df -h to see what i mean.

Not to get bogged down in semantics and all that, but /srv/ is nice for this stuff, and the "correct" place according to the FHS. Maybe we could do a /srv/abs -> /home/abs link due to size constraints?

eliott

5:39 p.m.

On 1/7/08, Aaron Griffin wrote:

...

On Jan 6, 2008 4:53 PM, eliott wrote:

...
Keep in mind that with the way gerolde is setup, /home has lots of space, while some of the other mount points do not. :/

Do a df -h to see what i mean.

Not to get bogged down in semantics and all that, but /srv/ is nice for this stuff, and the "correct" place according to the FHS.

Maybe we could do a /srv/abs -> /home/abs link due to size constraints?

I would rather not have symlinks laying around just to underhandedly maintain the FHS spec on our server. If the size of a full abs checkout isn't too large, we can just slap it under /srv/abs and keep an eye on it. Maybe you could do a test on it travis, before we roll out an implementation, to see how much space is used for a full checkout of all the repos?

Travis Willard

6:23 p.m.

On Jan 7, 2008 12:39 PM, eliott wrote:

...

On 1/7/08, Aaron Griffin wrote:

...
On Jan 6, 2008 4:53 PM, eliott wrote:

...
Keep in mind that with the way gerolde is setup, /home has lots of space, while some of the other mount points do not. :/

Do a df -h to see what i mean.

Not to get bogged down in semantics and all that, but /srv/ is nice for this stuff, and the "correct" place according to the FHS.

Maybe we could do a /srv/abs -> /home/abs link due to size constraints?

I would rather not have symlinks laying around just to underhandedly maintain the FHS spec on our server. If the size of a full abs checkout isn't too large, we can just slap it under /srv/abs and keep an eye on it.

Maybe you could do a test on it travis, before we roll out an implementation, to see how much space is used for a full checkout of all the repos?

Good plan - I'll do that along with testing of the rsync abs - when I get to it. Hopefully this week sometime.

Dan McGee

6:41 p.m.

On Jan 7, 2008 12:23 PM, Travis Willard wrote:

...

On Jan 7, 2008 12:39 PM, eliott wrote:

...

...
Maybe you could do a test on it travis, before we roll out an implementation, to see how much space is used for a full checkout of all the repos?

Good plan - I'll do that along with testing of the rsync abs - when I get to it. Hopefully this week sometime.

$ du -s -c community core extra testing unstable 26492 community 8236 core 33428 extra 4908 testing 1840 unstable 74904 total

eliott

7:11 p.m.

On 1/7/08, Dan McGee wrote:

...

On Jan 7, 2008 12:23 PM, Travis Willard wrote:

...
On Jan 7, 2008 12:39 PM, eliott wrote:

...
...
Maybe you could do a test on it travis, before we roll out an implementation, to see how much space is used for a full checkout of all the repos?

Good plan - I'll do that along with testing of the rsync abs - when I get to it. Hopefully this week sometime.

$ du -s -c community core extra testing unstable 26492 community 8236 core 33428 extra 4908 testing 1840 unstable 74904 total

dood. Use the -h option. ;)

5979

Age (days ago)

5982

Last active (days ago)

List overview

Download

25 comments

6 participants

participants (6)

Aaron Griffin
Dan McGee
eliott
Eric Belanger
Travis Willard
Xavier