On 05/05/2011 12:59 PM, Thomas Bächler wrote:

Am 05.05.2011 17:50, schrieb Dieter Plaetinck:

...

the size of core-dual iso has been over 700MB for a while. the last one is 738MB. See http://releng.archlinux.org/isos/2011.04.30/

what would be the best way to fix this? different archiso2dual parameters? different compression somewhere? revised packagelist? moving some packages out of core? [is anyone aware of noticeable size increases of the core repo or core packages?] I will change the default -c from gzip to xz in fews minutes. (There is no autodetection) Do we have xz-compressed squashfs already? yes. These images can still be written to DVD or USB, so they are not entirely useless.

Sure. Personally, I always use DVD-R even for smaller things in these days, bah! usb-keys. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

On 05/06/2011 02:12 AM, Thomas Dziedzic wrote:

On Thu, May 5, 2011 at 6:42 PM, Loui Chang wrote:

...

On Thu 05 May 2011 17:50 +0200, Dieter Plaetinck wrote:

...

the size of core-dual iso has been over 700MB for a while. the last one is 738MB. See http://releng.archlinux.org/isos/2011.04.30/

what would be the best way to fix this? different archiso2dual parameters? different compression somewhere? revised packagelist? moving some packages out of core? [is anyone aware of noticeable size increases of the core repo or core packages?] Perhaps it's time to deprecate the CD-R space requirement?

That sounds reasonable to me, I've been putting net installs on dvds for a while now :P If you want both core arch install cds, you could just burn 2 cds instead of 1. Less convenient but shouldn't affect a lot, if any users.

Just my 2 cents.

-Thomas Dziedzic I agree completely. CD is fairly ancient and even DVD is rather old. We are Arch for we are progressive. Let's deprecate the CD space limit.

-- Sven-Hendrik

On 05/05/2011 09:25 PM, Allan McRae wrote:

On 06/05/11 01:50, Dieter Plaetinck wrote:

...

the size of core-dual iso has been over 700MB for a while. the last one is 738MB. See http://releng.archlinux.org/isos/2011.04.30/

what would be the best way to fix this? different archiso2dual parameters? different compression somewhere? revised packagelist? moving some packages out of core? [is anyone aware of noticeable size increases of the core repo or core packages?]

You can get rid of gcc-{fortran,objc,ada,go} which are only in [core] due to limitations of our repo scripts.

Allan

$ pacman -Si gcc-ada gcc-fortran gcc-go gcc-objc | awk '/^Do/{p=p+$4}; END{print p,p*2}' 27745.7 55491.4 We can skip these packages in download-repo.sh. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

On 06/05/11 17:31, Dieter Plaetinck wrote:

On Thu, 05 May 2011 21:38:14 -0300 Gerardo Exequiel Pozzi wrote:

...

On 05/05/2011 09:25 PM, Allan McRae wrote:

...

On 06/05/11 01:50, Dieter Plaetinck wrote:

...

the size of core-dual iso has been over 700MB for a while. the last one is 738MB. See http://releng.archlinux.org/isos/2011.04.30/

what would be the best way to fix this? different archiso2dual parameters? different compression somewhere? revised packagelist? moving some packages out of core? [is anyone aware of noticeable size increases of the core repo or core packages?]

You can get rid of gcc-{fortran,objc,ada,go} which are only in [core] due to limitations of our repo scripts.

Allan

$ pacman -Si gcc-ada gcc-fortran gcc-go gcc-objc | awk '/^Do/{p=p+$4}; END{print p,p*2}' 27745.7 55491.4

We can skip these packages in download-repo.sh.

I agree we shouldn't restrict ourselves any longer to cd-r size limitations, OTOH if we can keep our images<700MB with relative ease and that way support cd-r's, then i prefer that. also: optimizing size is always useful. (less storage/bandwith intensive)

adding exceptions in download-repo.sh to work around limitations in our repo scripts is not the way to go imho. let's get those packages out of core the proper way, and let's see if/how we can cut another 10MB.

That limitation in the devtools/db-scripts has been around ever since split packages became available in pacman/makepkg. I would not bank on it getting fixed in the short term (or even in the long term...) Allan

On Fri, 06 May 2011 17:45:13 +1000, Allan McRae wrote:

On 06/05/11 17:31, Dieter Plaetinck wrote:

...

On Thu, 05 May 2011 21:38:14 -0300 adding exceptions in download-repo.sh to work around limitations in our repo scripts is not the way to go imho. let's get those packages out of core the proper way, and let's see if/how we can cut another 10MB.

That limitation in the devtools/db-scripts has been around ever since split packages became available in pacman/makepkg. I would not bank on it getting fixed in the short term (or even in the long term...)

I wont got into details here but putting split packages into different repos is a "wont implement". It's more a limitation of how we use svn and the repos. There was a thread about the details on the mailing list. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

On Sun, May 15, 2011 at 5:25 AM, Dieter Plaetinck wrote:

On Fri, 06 May 2011 15:28:29 +0200 Pierre Schmitz wrote:

...

On Fri, 06 May 2011 17:45:13 +1000, Allan McRae wrote:

...

On 06/05/11 17:31, Dieter Plaetinck wrote:

...

On Thu, 05 May 2011 21:38:14 -0300 adding exceptions in download-repo.sh to work around limitations in our repo scripts is not the way to go imho.  let's get those packages out of core the proper way, and let's see if/how we can cut another 10MB.

That limitation in the devtools/db-scripts has been around ever since split packages became available in pacman/makepkg.   I would not bank on it getting fixed in the short term  (or even in the long term...)

I wont got into details here but putting split packages into different repos is a "wont implement". It's more a limitation of how we use svn and the repos. There was a thread about the details on the mailing list.

I can't find that thread. Where exactly was this discussed? I understand this is probably hard to fix, on the other hand: 1) this is a violation of what the core repository is for (and we had a very extensive discussion on that recently). see https://wiki.archlinux.org/index.php/Official_repositories#.5Bcore.5D 2) it makes the core repo bigger than it should be, which makes my job harder.

Not to sound like an ass, but your poor attitude comes across here and makes anyone that might look at this back away because we'll probably still do it wrong. Patches welcome since you seem to think it is so trivial to implement- Pierre clearly stated why we aren't able to do this at this time and you still just fired back with the same policy BS. We're all doing this for fun, and being told our work isn't good enough really sucks the fun out of it. Pierre has done a really good job at making our dbscripts a lot more robust and under test coverage and you really are taking a low blow here. -Dan

On Sun, May 15, 2011 at 11:45 AM, Dieter Plaetinck wrote:

On Sun, 15 May 2011 11:09:02 -0500 Dan McGee wrote: Hi Dan,

...

since you seem to think it is so trivial to implement- I actually said the exact opposite. Maybe you should read what I said first. I'll eat crow here on this one, I apologize. Looking back at it, I missed your "I understand this is probably hard to fix, on the other hand" line. Sorry about that.

...

Pierre clearly stated why we aren't able to do this at this time He only referred to a prior discussion which I could not find back, so I asked for the link.

...

being told our work isn't good enough really sucks the fun out of it. (blah blah blah) Not to sound like an ass,

putting words I didn't say in my mouth and flaming me does make you sound like one.

I guess it can sometimes be hard to interpret the intention behind my (or anyone elses) e-mails, which can have caused a misunderstanding.  Either way bad-mouthing anyone was not my intention. I think it just comes down to an attitude misunderstanding, so I apologize. I got a bit worked up when your email ended with "which makes my job harder", which just rubs me the wrong way- we all do work around here, and saying that makes it sound like it isn't focused correctly in your eyes as it isn't doing enough to serve your purposes.

I will make sure I fully read your emails from here on out and not interpret them as carrying malicious intent, but I do also encourage you to watch the way you put things- it can come across as very demeaning of other peoples efforts. -Dan