Continuing a discussion from earlier, on into a fresh thread.
We need a plan for the additional ISOs.
To reiterate what's going on here:
There are a handful of users who would like to have a giant iso of packages to aid in installing on boxes with slower networks (for instance, they could download and burn the ISOs from school).
So, I've seen a few ideas, and Thomas seems to have the best grasp on what is slated.
Here's what I'd like to see:
* A small script which constructs a repo from a list of packages, then runs mkisofs on it. This would allow users to very easily create a CD or DVD full of packages THEY want.
* One or two officially built ISOs (CD? DVD?) using the above tool, with some nice utilities and tools, etc.
* Perhaps a combination of the two, and a bootable "OMGHUGE" DVD.
Opinions, what do you guys think? I haven't really heard much comment on this topic so far.
Thanks in advance, Aaron
Friday 28 September 2007, Aaron Griffin wrote: | * A small script which constructs a repo from a list of packages, | then runs mkisofs on it. This would allow users to very easily | create a CD or DVD full of packages THEY want.
+1 maybe in addition to the script, if the downloading needs to happen at school (windows, mac!) it is maybe helpful to provide in addition an easy xsl(mozilla) or java tool for this (platform independend). or we provide the script in all platform versions. or the script is run by webinterface and the iso file is generated on the server a priori to downloading it.
| * One or two officially built ISOs (CD? DVD?) using the above | tool, with some nice utilities and tools, etc.
-1 if this huge thing is going to be shared over the server. using decentralised sharing is ok by me (torrents). otherwise, it will eat up our traffick, since users are downloading such things just to have them... and if they are rebuilt every day or every time the repo is updated, a pkg is updated or every week, i'm sure some users would like to download every version, no matter if they use it.
humans like collecting nice shining things ;)
| * Perhaps a combination of the two, and a bootable "OMGHUGE" DVD.
hmm... i'm undecided if we need a big bootable image. usually, having a CD full of material is more than enough to get started. then you can just mount the "OMGHUGE" medium to access another repository on your already running system.
instead i have a conter-proposition: we need a prespecified repo on optical drive in pacman.conf (e.g. /media/mobilerepo/os/i686 or something like this) and then this huge additional medium has the repo at exactly this place. i think with a medium label kept unique and HAL you can make it mount automatically and always at /media/mobilerepo
- D
On Fri, Sep 28, 2007 at 01:59:00AM +0200, Damir Perisa wrote:
Friday 28 September 2007, Aaron Griffin wrote: | * A small script which constructs a repo from a list of packages, | then runs mkisofs on it. This would allow users to very easily | create a CD or DVD full of packages THEY want.
+1 maybe in addition to the script, if the downloading needs to happen at school (windows, mac!) it is maybe helpful to provide in addition an easy xsl(mozilla) or java tool for this (platform independend). or we provide the script in all platform versions. or the script is run by webinterface and the iso file is generated on the server a priori to downloading it.
-1 on the xsl or java tool at least initially. I'm not going to write it or maintain it... it will have to stay in sync with all the other code we have in pacman.
| * One or two officially built ISOs (CD? DVD?) using the above | tool, with some nice utilities and tools, etc.
-1 if this huge thing is going to be shared over the server. using decentralised sharing is ok by me (torrents). otherwise, it will eat up our traffick, since users are downloading such things just to have them... and if they are rebuilt every day or every time the repo is updated, a pkg is updated or every week, i'm sure some users would like to download every version, no matter if they use it.
humans like collecting nice shining things ;)
Having a new package DVD that comes out the same time as the install CD is just fine by me (maybe not for bugfix install CDs).
| * Perhaps a combination of the two, and a bootable "OMGHUGE" DVD.
hmm... i'm undecided if we need a big bootable image. usually, having a CD full of material is more than enough to get started. then you can just mount the "OMGHUGE" medium to access another repository on your already running system.
I don't mind non-bootable repository DVDs... most other distros do that and you don't really need all the packages available when you're making your initial install.
instead i have a conter-proposition: we need a prespecified repo on optical drive in pacman.conf (e.g. /media/mobilerepo/os/i686 or something like this) and then this huge additional medium has the repo at exactly this place. i think with a medium label kept unique and HAL you can make it mount automatically and always at /media/mobilerepo
I do mind automounting the medium to a special place. If someone needs to mount a repo DVD, there should be instructions somewhere and it shouldn't be very hard to do anyway (1. edit /etc/pacman.conf 2. mount DVD). Doing something special to access this DVD in a different place is a bad idea.
Jason
Friday 28 September 2007, Jason Chu wrote: | On Fri, Sep 28, 2007 at 01:59:00AM +0200, Damir Perisa wrote: | > Friday 28 September 2007, Aaron Griffin wrote: | > | * A small script which constructs a repo from a list of | > | packages, then runs mkisofs on it. This would allow users to | > | very easily create a CD or DVD full of packages THEY want. | > | > +1 | > maybe in addition to the script, if the downloading needs to | > happen at school (windows, mac!) it is maybe helpful to provide | > in addition an easy xsl(mozilla) or java tool for this (platform | > independend). or we provide the script in all platform versions. | > or the script is run by webinterface and the iso file is | > generated on the server a priori to downloading it. | | -1 on the xsl or java tool at least initially. I'm not going to | write it or maintain it... it will have to stay in sync with all | the other code we have in pacman.
not pacman but repositories. it would be a rewrite in java of pacman fetching and dependency resolving mechanism.
| > instead i have a conter-proposition: we need a prespecified repo | > on optical drive in pacman.conf (e.g. /media/mobilerepo/os/i686 | > or something like this) and then this huge additional medium has | > the repo at exactly this place. i think with a medium label kept | > unique and HAL you can make it mount automatically and always | > at /media/mobilerepo | | I do mind automounting the medium to a special place. If someone | needs to mount a repo DVD, there should be instructions somewhere | and it shouldn't be very hard to do anyway (1. edit | /etc/pacman.conf 2. mount DVD). Doing something special to access | this DVD in a different place is a bad idea.
i agree about the "special". the idea behind special is to be "same" for all archlinux installations. this way, the 1) edit pacman.conf would just mean removing the #, since every machine mounts the additional media with additional repo on the same place. the whole thing however is purely detail. i agree with you that making it very special is not needed... but if somebody has two optical drives, the disc will be HAL-mounted in /media/cd or /media/cd1 or wherever, but if you specify a rule on the label for example, then it will always be where we want it to be, making editing pacman.conf obsolete.
- D
On Fri, Sep 28, 2007 at 03:22:53AM +0200, Damir Perisa wrote:
Friday 28 September 2007, Jason Chu wrote: | On Fri, Sep 28, 2007 at 01:59:00AM +0200, Damir Perisa wrote: | > Friday 28 September 2007, Aaron Griffin wrote: | > | * A small script which constructs a repo from a list of | > | packages, then runs mkisofs on it. This would allow users to | > | very easily create a CD or DVD full of packages THEY want. | > | > +1 | > maybe in addition to the script, if the downloading needs to | > happen at school (windows, mac!) it is maybe helpful to provide | > in addition an easy xsl(mozilla) or java tool for this (platform | > independend). or we provide the script in all platform versions. | > or the script is run by webinterface and the iso file is | > generated on the server a priori to downloading it. | | -1 on the xsl or java tool at least initially. I'm not going to | write it or maintain it... it will have to stay in sync with all | the other code we have in pacman.
not pacman but repositories. it would be a rewrite in java of pacman fetching and dependency resolving mechanism.
And the repository generation code...
| > instead i have a conter-proposition: we need a prespecified repo | > on optical drive in pacman.conf (e.g. /media/mobilerepo/os/i686 | > or something like this) and then this huge additional medium has | > the repo at exactly this place. i think with a medium label kept | > unique and HAL you can make it mount automatically and always | > at /media/mobilerepo | | I do mind automounting the medium to a special place. If someone | needs to mount a repo DVD, there should be instructions somewhere | and it shouldn't be very hard to do anyway (1. edit | /etc/pacman.conf 2. mount DVD). Doing something special to access | this DVD in a different place is a bad idea.
i agree about the "special". the idea behind special is to be "same" for all archlinux installations. this way, the 1) edit pacman.conf would just mean removing the #, since every machine mounts the additional media with additional repo on the same place. the whole thing however is purely detail. i agree with you that making it very special is not needed... but if somebody has two optical drives, the disc will be HAL-mounted in /media/cd or /media/cd1 or wherever, but if you specify a rule on the label for example, then it will always be where we want it to be, making editing pacman.conf obsolete.
Yeah, but the argument is changing a couple characters in a commented out /etc/pacman.conf line or pre-configuring HAL to mount a disk with a certain label in a different place. I really think that the pacman.conf edit will be easier.
Jason
Friday 28 September 2007, Jason Chu wrote: | On Fri, Sep 28, 2007 at 03:22:53AM +0200, Damir Perisa wrote: | > Friday 28 September 2007, Jason Chu wrote: | > | On Fri, Sep 28, 2007 at 01:59:00AM +0200, Damir Perisa wrote: | > | > Friday 28 September 2007, Aaron Griffin wrote: | > | > | * A small script which constructs a repo from a list of | > | > | packages, then runs mkisofs on it. This would allow | > | > | users to very easily create a CD or DVD full of packages | > | > | THEY want. | > | > | > | > +1 | > | > maybe in addition to the script, if the downloading needs | > | > to happen at school (windows, mac!) it is maybe helpful to | > | > provide in addition an easy xsl(mozilla) or java tool for | > | > this (platform independend). or we provide the script in | > | > all platform versions. or the script is run by webinterface | > | > and the iso file is generated on the server a priori to | > | > downloading it. | > | | > | -1 on the xsl or java tool at least initially. I'm not going | > | to write it or maintain it... it will have to stay in sync | > | with all the other code we have in pacman. | > | > not pacman but repositories. it would be a rewrite in java of | > pacman fetching and dependency resolving mechanism. | | And the repository generation code...
right :)
| > | > instead i have a conter-proposition: we need a prespecified | > | > repo on optical drive in pacman.conf (e.g. | > | > /media/mobilerepo/os/i686 or something like this) and then | > | > this huge additional medium has the repo at exactly this | > | > place. i think with a medium label kept unique and HAL you | > | > can make it mount automatically and always at | > | > /media/mobilerepo | > | | > | I do mind automounting the medium to a special place. If | > | someone needs to mount a repo DVD, there should be | > | instructions somewhere and it shouldn't be very hard to do | > | anyway (1. edit | > | /etc/pacman.conf 2. mount DVD). Doing something special to | > | access this DVD in a different place is a bad idea. | > | > i agree about the "special". the idea behind special is to be | > "same" for all archlinux installations. this way, the 1) edit | > pacman.conf would just mean removing the #, since every machine | > mounts the additional media with additional repo on the same | > place. the whole thing however is purely detail. i agree with | > you that making it very special is not needed... but if somebody | > has two optical drives, the disc will be HAL-mounted in | > /media/cd or /media/cd1 or wherever, but if you specify a rule | > on the label for example, then it will always be where we want | > it to be, making editing pacman.conf obsolete. | | Yeah, but the argument is changing a couple characters in a | commented out /etc/pacman.conf line or pre-configuring HAL to | mount a disk with a certain label in a different place. I really | think that the pacman.conf edit will be easier.
ok
- D
Am Thu, 27 Sep 2007 18:33:09 -0500 schrieb "Aaron Griffin" aaronmgriffin@gmail.com:
Opinions, what do you guys think? I haven't really heard much comment on this topic so far.
-1 from me
Whoever will maintain such a script it will be very hard to satisfy all license issue. I prefer to solve the license issue first. Either let's move license critical packages into a certain non-free repo or mark them in their pkgbuild with some kind of a tag. I'd like to have the non-free repo solution.
Andy
On 9/27/07, Andreas Radke a.radke@arcor.de wrote:
Am Thu, 27 Sep 2007 18:33:09 -0500 schrieb "Aaron Griffin" aaronmgriffin@gmail.com:
Opinions, what do you guys think? I haven't really heard much comment on this topic so far.
-1 from me
Whoever will maintain such a script it will be very hard to satisfy all license issue. I prefer to solve the license issue first. Either let's move license critical packages into a certain non-free repo or mark them in their pkgbuild with some kind of a tag. I'd like to have the non-free repo solution.
I'm so confused here! The _script_ should not care at ALL about license issues, that is why the script will take a package list! It is up to the person generating the ISO or package bundle to ensure they are in compliance with any license issues, not the script.
-Dan
On 9/27/07, Dan McGee dpmcgee@gmail.com wrote:
On 9/27/07, Andreas Radke a.radke@arcor.de wrote:
Am Thu, 27 Sep 2007 18:33:09 -0500 schrieb "Aaron Griffin" aaronmgriffin@gmail.com:
Opinions, what do you guys think? I haven't really heard much comment on this topic so far.
-1 from me
Whoever will maintain such a script it will be very hard to satisfy all license issue. I prefer to solve the license issue first. Either let's move license critical packages into a certain non-free repo or mark them in their pkgbuild with some kind of a tag. I'd like to have the non-free repo solution.
I'm so confused here! The _script_ should not care at ALL about license issues, that is why the script will take a package list! It is up to the person generating the ISO or package bundle to ensure they are in compliance with any license issues, not the script.
Yeah Dan got what I was intending.
What I mean is a script that just uses a file that lists packages to build us a nice big fat ISO. I really doubt it'd be much more than a pacman --root=foo/, repo-add, and mkisofs.
This way, through human interaction, we can specifically manage any and all license issues.
2007/9/28, Aaron Griffin aaronmgriffin@gmail.com:
On 9/27/07, Dan McGee dpmcgee@gmail.com wrote:
On 9/27/07, Andreas Radke a.radke@arcor.de wrote:
Am Thu, 27 Sep 2007 18:33:09 -0500 schrieb "Aaron Griffin" aaronmgriffin@gmail.com:
Opinions, what do you guys think? I haven't really heard much comment on this topic so far.
-1 from me
Whoever will maintain such a script it will be very hard to satisfy all license issue. I prefer to solve the license issue first. Either let's move license critical packages into a certain non-free repo or mark them in their pkgbuild with some kind of a tag. I'd like to have the non-free repo solution.
I'm so confused here! The _script_ should not care at ALL about license issues, that is why the script will take a package list! It is up to the person generating the ISO or package bundle to ensure they are in compliance with any license issues, not the script.
Yeah Dan got what I was intending.
What I mean is a script that just uses a file that lists packages to build us a nice big fat ISO. I really doubt it'd be much more than a pacman --root=foo/, repo-add, and mkisofs.
This way, through human interaction, we can specifically manage any and all license issues.
I don't mind about such script, of course. But since we're going to provide our own official OMGHUGE ISO - that would be we who will need to check those packages for license then. ;-) Since license support in pacman is not on the top of current priorities now and IMHO non-free repo is simpler aproach to solving such issues - I agree with Andy here.
About CD sets vs DVD, bootable vs non-bootable:
1) I don't know if it would be easy to make a bootable set of CDs with packages - this would certainly require changes to installer. I see two possibilities here: a) arrange packages in a way that all dependencies for any given package should exist on a previous CD (I wonder if it can be done). b) do not care about the order of packages but installer should -Sw them first, so they will be stored in pacman's cache on HDD, and then -S them.
2) Providing a set of CD ISOs with just packages on them is simpler (users will have to install from core ISO and then just mount such CD and copy all packages to HDD or straight into pacman's cache). I makes no big difference in downloading few isos or few thousands of packages, users can write packages on CDs by themselves even from Windows box. But in that case the entire list of packages should be snapshotted (users may download these files during few days which would make the list outsynced).
3) As for DVD - I think making it installable is easy and costs nothing, so it would be very nice to have one bootable InstallDVD with all official repos and another with community.
On Fri, Sep 28, 2007 at 12:00:27PM +0300, Roman Kyrylych wrote:
2007/9/28, Aaron Griffin aaronmgriffin@gmail.com:
On 9/27/07, Dan McGee dpmcgee@gmail.com wrote:
On 9/27/07, Andreas Radke a.radke@arcor.de wrote:
Am Thu, 27 Sep 2007 18:33:09 -0500 schrieb "Aaron Griffin" aaronmgriffin@gmail.com:
Opinions, what do you guys think? I haven't really heard much comment on this topic so far.
-1 from me
Whoever will maintain such a script it will be very hard to satisfy all license issue. I prefer to solve the license issue first. Either let's move license critical packages into a certain non-free repo or mark them in their pkgbuild with some kind of a tag. I'd like to have the non-free repo solution.
I'm so confused here! The _script_ should not care at ALL about license issues, that is why the script will take a package list! It is up to the person generating the ISO or package bundle to ensure they are in compliance with any license issues, not the script.
Yeah Dan got what I was intending.
What I mean is a script that just uses a file that lists packages to build us a nice big fat ISO. I really doubt it'd be much more than a pacman --root=foo/, repo-add, and mkisofs.
This way, through human interaction, we can specifically manage any and all license issues.
I don't mind about such script, of course. But since we're going to provide our own official OMGHUGE ISO - that would be we who will need to check those packages for license then. ;-) Since license support in pacman is not on the top of current priorities now and IMHO non-free repo is simpler aproach to solving such issues - I agree with Andy here.
I really don't think pacman needs to have license support. When we create the ISO we will have a list of packages we want to build the ISO repo from. That list of packages won't include any packages that we aren't allowed to distribute. Tada.
Jason
On 9/28/07, Jason Chu jason@archlinux.org wrote:
On Fri, Sep 28, 2007 at 12:00:27PM +0300, Roman Kyrylych wrote:
2007/9/28, Aaron Griffin aaronmgriffin@gmail.com:
On 9/27/07, Dan McGee dpmcgee@gmail.com wrote:
On 9/27/07, Andreas Radke a.radke@arcor.de wrote:
Am Thu, 27 Sep 2007 18:33:09 -0500 schrieb "Aaron Griffin" aaronmgriffin@gmail.com:
Opinions, what do you guys think? I haven't really heard much comment on this topic so far.
-1 from me
Whoever will maintain such a script it will be very hard to satisfy all license issue. I prefer to solve the license issue first. Either let's move license critical packages into a certain non-free repo or mark them in their pkgbuild with some kind of a tag. I'd like to have the non-free repo solution.
I'm so confused here! The _script_ should not care at ALL about license issues, that is why the script will take a package list! It is up to the person generating the ISO or package bundle to ensure they are in compliance with any license issues, not the script.
Yeah Dan got what I was intending.
What I mean is a script that just uses a file that lists packages to build us a nice big fat ISO. I really doubt it'd be much more than a pacman --root=foo/, repo-add, and mkisofs.
This way, through human interaction, we can specifically manage any and all license issues.
I don't mind about such script, of course. But since we're going to provide our own official OMGHUGE ISO - that would be we who will need to check those packages for license then. ;-) Since license support in pacman is not on the top of current priorities now and IMHO non-free repo is simpler aproach to solving such issues - I agree with Andy here.
I really don't think pacman needs to have license support. When we create the ISO we will have a list of packages we want to build the ISO repo from. That list of packages won't include any packages that we aren't allowed to distribute. Tada.
Yeah, see. Jason (and Dan, earlier) has the right of it here. I think this is (again) blown out of proportion. We all know there are license issues with some packages. That's the way this works.
So how do we solve this? We *explicitly* list packages that should be installed. It's no different if someone creates a "nonfree" repo (which we don't want to do) - they are still listing packages they are allowing.
The simplest way to "list packages" like this? A text file. We don't need web interfaces. We don't need java tools. We don't need this crap.
We need a text file.
This isn't rocket surgery here. We're not trying to solve complex license issues. We're trying to make a list of packages we want to distribute.
2007/9/28, Aaron Griffin aaronmgriffin@gmail.com:
Yeah, see. Jason (and Dan, earlier) has the right of it here. I think this is (again) blown out of proportion. We all know there are license issues with some packages. That's the way this works.
So how do we solve this? We *explicitly* list packages that should be installed. It's no different if someone creates a "nonfree" repo (which we don't want to do) - they are still listing packages they are allowing.
The simplest way to "list packages" like this? A text file. We don't need web interfaces. We don't need java tools. We don't need this crap.
We need a text file.
This isn't rocket surgery here. We're not trying to solve complex license issues. We're trying to make a list of packages we want to distribute.
I think it is _much_ easier to create a list of packages we _don't_ want to distribute. ;-P So we can ship everything except those in that list.
On 9/28/07, Roman Kyrylych roman.kyrylych@gmail.com wrote:
I think it is _much_ easier to create a list of packages we _don't_ want to distribute. ;-P So we can ship everything except those in that list.
Sure, but that's semantics. A list of explicitly denied packages can easily be transformed into a list of explicitly allowed packages (the term is "set difference" in mathematics).
Friday 28 September 2007, Aaron Griffin wrote: | On 9/28/07, Roman Kyrylych roman.kyrylych@gmail.com wrote: | > I think it is _much_ easier to create a list of packages we | > _don't_ want to distribute. ;-P | > So we can ship everything except those in that list. | | Sure, but that's semantics. A list of explicitly denied packages | can easily be transformed into a list of explicitly allowed | packages (the term is "set difference" in mathematics).
if you knwo the complete set, yes.
- D
On 9/28/07, Damir Perisa damir.perisa@solnet.ch wrote:
Friday 28 September 2007, Aaron Griffin wrote: | On 9/28/07, Roman Kyrylych roman.kyrylych@gmail.com wrote: | > I think it is _much_ easier to create a list of packages we | > _don't_ want to distribute. ;-P | > So we can ship everything except those in that list. | | Sure, but that's semantics. A list of explicitly denied packages | can easily be transformed into a list of explicitly allowed | packages (the term is "set difference" in mathematics).
if you knwo the complete set, yes.
ls ~/my_checkout/extra/*/* ?
On 9/28/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 9/28/07, Damir Perisa damir.perisa@solnet.ch wrote:
Friday 28 September 2007, Aaron Griffin wrote: | On 9/28/07, Roman Kyrylych roman.kyrylych@gmail.com wrote: | > I think it is _much_ easier to create a list of packages we | > _don't_ want to distribute. ;-P | > So we can ship everything except those in that list. | | Sure, but that's semantics. A list of explicitly denied packages | can easily be transformed into a list of explicitly allowed | packages (the term is "set difference" in mathematics).
if you knwo the complete set, yes.
pacman -Sl extra | comm -3 excludedpackages.txt -
-Dan
Friday 28 September 2007, Dan McGee wrote: | On 9/28/07, Aaron Griffin aaronmgriffin@gmail.com wrote: | > On 9/28/07, Damir Perisa damir.perisa@solnet.ch wrote: | > > Friday 28 September 2007, Aaron Griffin wrote: | > > | On 9/28/07, Roman Kyrylych roman.kyrylych@gmail.com wrote: | > > | > I think it is _much_ easier to create a list of packages | > > | > we _don't_ want to distribute. ;-P | > > | > So we can ship everything except those in that list. | > > | | > > | Sure, but that's semantics. A list of explicitly denied | > > | packages can easily be transformed into a list of | > > | explicitly allowed packages (the term is "set difference" | > > | in mathematics). | > > | > > if you knwo the complete set, yes. | | pacman -Sl extra | comm -3 excludedpackages.txt -
true... i forgot, that oyu can remotely list all the pkgs in a repo that easily. (Sl)
- D
Am Thu, 27 Sep 2007 18:33:09 -0500 schrieb "Aaron Griffin" aaronmgriffin@gmail.com:
There are a handful of users who would like to have a giant iso of packages to aid in installing on boxes with slower networks (for instance, they could download and burn the ISOs from school).
I think _now_ a huge iso doesn't make much sense. Remember we are running a rolling release distribution. We often have .so bumps and packages move from and out of core repo. Packages come and go. It would force us to almost daily create such a huge_iso. Our rolling release distribution forces most users to have a good internet connection. A very quick outdated huge_iso is not very helpful in this case though some might find it helpful.
But this all would change when we offer a _NON_rolling release distribution. Then a fixed and free of license issues ISO-set is a must.
Some of you might know that I have the intention to maintain and release a rockstable fixed distribution based on ArchLinux. But that's another topic ;)
Andy
On 9/28/07, Andreas Radke a.radke@arcor.de wrote:
Packages come and go. It would force us to almost daily create such a huge_iso.
Here's the funny thing about the script I proposed. It is a script. It requires no human interaction.
If you feel it is critical to have daily package ISOs (I do not, but we can decide this later), I will gladly run it as a cron job and upload it to gerolde.
2007/9/28, Andreas Radke a.radke@arcor.de:
Am Thu, 27 Sep 2007 18:33:09 -0500 schrieb "Aaron Griffin" aaronmgriffin@gmail.com:
There are a handful of users who would like to have a giant iso of packages to aid in installing on boxes with slower networks (for instance, they could download and burn the ISOs from school).
I think _now_ a huge iso doesn't make much sense. Remember we are running a rolling release distribution. We often have .so bumps and packages move from and out of core repo. Packages come and go. It would force us to almost daily create such a huge_iso. Our rolling release distribution forces most users to have a good internet connection. A very quick outdated huge_iso is not very helpful in this case though some might find it helpful.
But this all would change when we offer a _NON_rolling release distribution. Then a fixed and free of license issues ISO-set is a must.
Why should we have to release such ISO daily? We will release it at the same time as Core & FTP ISOs. If some package(s) will have some bugs or even would be broken - no big deal. The mission of huge ISO is to give people a quick start, especially those with slow Internet, not to be a rock-stable working release.
Saturday 29 September 2007, Roman Kyrylych wrote: | Why should we have to release such ISO daily?
we do not have to. but who would like to download 4gb of data and then to find out that 1/4 of it needs an update in the meanwhile anyway, since it is old on the ISO.
the difference between the big iso and the repos will grow faster than the one of a small iso and the repos - that's the nature of things.
- D
2007/9/29, Damir Perisa damir.perisa@solnet.ch:
Saturday 29 September 2007, Roman Kyrylych wrote: | Why should we have to release such ISO daily?
we do not have to. but who would like to download 4gb of data and then to find out that 1/4 of it needs an update in the meanwhile anyway, since it is old on the ISO.
Come on, not 1/4 in reality. ;-)
the difference between the big iso and the repos will grow faster than the one of a small iso and the repos - that's the nature of things.
Yes, but again - in real situations users were happy with a repo snapshot and have no big issues with downloading some missing packages (because of some broken/outofsync depends etc.).
I'm getting tired of such discussions... I think we should let Thomas do an implementation of this and see how it works.
Saturday 29 September 2007, Roman Kyrylych wrote: | 2007/9/29, Damir Perisa damir.perisa@solnet.ch: | > Saturday 29 September 2007, Roman Kyrylych wrote: | > | Why should we have to release such ISO daily? | > | > we do not have to. but who would like to download 4gb of data | > and then to find out that 1/4 of it needs an update in the | > meanwhile anyway, since it is old on the ISO. | | Come on, not 1/4 in reality. ;-)
rough estimate of amount of updates in 4 months
| > the difference between the big iso and the repos will grow | > faster than the one of a small iso and the repos - that's the | > nature of things. | | Yes, but again - in real situations users were happy with a repo | snapshot and have no big issues with downloading some missing | packages (because of some broken/outofsync depends etc.).
my argument is not about missing packages but outdatedness and the speed of it. it is no argument in a discussion but a statement, that any big iso would become faster outdated than a smaller one.
| I'm getting tired of such discussions... | I think we should let Thomas do an implementation of this and see | how it works.
i'm not holding him from implementing anything. if it itches, scratch :) that's the way things work here i heard some wise guy write... ;)
... i'm not discussing anything, i'm just giving input somebody may find helpful, somebody may care to see this point of view.
- D
arch-dev-public@lists.archlinux.org