From Fedora Project Wiki
No edit summary |
No edit summary |
||
(5 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
** [[User:Bruno]]: I guess I am thinking the wording of the why those limits are recommended seems misleading. | ** [[User:Bruno]]: I guess I am thinking the wording of the why those limits are recommended seems misleading. | ||
** [[User:Bruno]]: And related to compression, lzma is going to eventually result in better (10-20%ish if I remember correctly) compression and may cause us to reevaluate those numbers. | ** [[User:Bruno]]: And related to compression, lzma is going to eventually result in better (10-20%ish if I remember correctly) compression and may cause us to reevaluate those numbers. | ||
** [[User:Bruno]]: If the performance hit isn't too large, I think recommending one size of say 12288, would simplify things for people making spin kickstarts. The 4 GiB should be checked at the end. Possibly livecd-creator should emit a warning if the resulting iso is over 4 GiB. | ** [[User:Bruno]]: If the performance hit isn't too large, I think recommending one size of say 12288, would simplify things for people making spin kickstarts. The 4 GiB iso size limit should be checked at the end. Possibly livecd-creator should emit a warning if the resulting iso is over 4 GiB. | ||
* [[User:Bruno]]: On the 4 GiB limit, I received some feedback that modern Windows systems (XP and later) can use NTFS which doesn't have the 4 GiB file restriction. And that it was not expected that a lot of people would want to store the iso images on USB flash drives which commonly use vfat. How true that is in practice, I don't know. | * [[User:Bruno]]: On the 4 GiB limit, I received some feedback that modern Windows systems (XP and later) can use NTFS which doesn't have the 4 GiB file restriction. And that it was not expected that a lot of people would want to store the iso images on USB flash drives which commonly use vfat. How true that is in practice, I don't know. | ||
* [[User:Bruno]]: On the compose requirements, do we want to say anything about script dependencies? (If nothing else, to make spin maintainers aware of the issue.) For example when I started looking at the games spin build, I saw a number install scripts that failed and filed bugs asking the package maintainers to fix the spec file so that things get installed in a correct order. | |||
* [[User:Bruno]]: I think it would be a good idea to have some proposed critera for how it will be decided which spins get published if the size or number limits get reached. | |||
* [[User:Bruno]]: On base kickstart files and package removal. Is it OK to specify a base kickstart, but then not include everything in that kickstart? For example for the games spin, I think it will be easier for me to trim things off the desktop spin rather than add things to the live base spin. | |||
* [[User:Bruno]]: There are no comments about architecures. Do live spins need to work on more than just i586? |
Latest revision as of 15:06, 18 January 2009
- User:Bruno: The part limits don't actually guaranty that the resulting image (iso or squashfs) will be a desired size. It will depend on the amount of compression you get. Using larger values will slow down a build at least somewhat, so we don't want them to be way larger than needed.
- Jeroen van Meeuwen: You're right, it doesn't. Because of this compression however, we need some way to prevent the compose from ending up oversized. These two sizes very roughly indicate where that magic boundary is. Of course if you fill 8192MB with a lot of plaintext files you're gonna end up with a smaller squashfs then when you fill it with a few large binaries.
- User:Bruno: I guess I am thinking the wording of the why those limits are recommended seems misleading.
- User:Bruno: And related to compression, lzma is going to eventually result in better (10-20%ish if I remember correctly) compression and may cause us to reevaluate those numbers.
- User:Bruno: If the performance hit isn't too large, I think recommending one size of say 12288, would simplify things for people making spin kickstarts. The 4 GiB iso size limit should be checked at the end. Possibly livecd-creator should emit a warning if the resulting iso is over 4 GiB.
- User:Bruno: On the 4 GiB limit, I received some feedback that modern Windows systems (XP and later) can use NTFS which doesn't have the 4 GiB file restriction. And that it was not expected that a lot of people would want to store the iso images on USB flash drives which commonly use vfat. How true that is in practice, I don't know.
- User:Bruno: On the compose requirements, do we want to say anything about script dependencies? (If nothing else, to make spin maintainers aware of the issue.) For example when I started looking at the games spin build, I saw a number install scripts that failed and filed bugs asking the package maintainers to fix the spec file so that things get installed in a correct order.
- User:Bruno: I think it would be a good idea to have some proposed critera for how it will be decided which spins get published if the size or number limits get reached.
- User:Bruno: On base kickstart files and package removal. Is it OK to specify a base kickstart, but then not include everything in that kickstart? For example for the games spin, I think it will be easier for me to trim things off the desktop spin rather than add things to the live base spin.
- User:Bruno: There are no comments about architecures. Do live spins need to work on more than just i586?