Hello, 2007/10/20, Danek Duvall <danek.duvall at sun.com>: > > On Fri, Oct 19, 2007 at 05:19:48PM -0500, Christopher Kampmeier wrote: > > > How does this approach relate to the situation where we will have a > > transportable disk image format for IPS packages? > > The fatness of a package in a repo can grow over time as more data is > added > to it -- new architectures, localizations, etc. A marshalled subset of > the > repo can be taken from the repo at any point in time with whatever > contents > are in there at that point. And, just as if you tried to install from the > repo at that point, installing from the serialized form may not give you > all the data that you might have gotten at a later point in time. > > > Will we only have fat packages in disk image form? > > You may have the option of pre-filtering the packages when you serialize > them (no need to pass around sparc and x86 bits if you only care about > x86). > > > If not, will a person handling the disk image form of a package readily > > understand the general type of content contained in the disk image? > > Just as there will need to be some method to query the repo to find out if > package P contains bits passing through filter F, there will need to be > some method to query a serialized subset of it for the same information.
Hmm, I didn't know that tag should be used for architecture... Because this makes lot's of troubles to creator of package. You have to build your software for different architectures. Even cross compiling is great tool, it's not bullet-proof tool and I'm against using it. Let's say that pkgbuild script will compile package for x86, amd64 and sparc. (By cross-compiling) if you were on amd64 - you have to test *two* binaries on same pc and go to some other sparc to test sparc platform! So after some time you will test 2 binaries and after more time only one and even later you would *not* test anything, because you say "I already don't test it for sparc and x64 so why do it for x86?". And problems will lurk from the dark soon and eat you! ;-) Maybe if it would be easy way to add new tagged data, then maybe ... But think about badly designed softwares, which have some arch specific data. Something like data file with path of binaries. Such file would need more tags (data, x64) and there can exist same file in terms of filename with tags (data, sparc)... Which can make filtering tags a bit complicated. Also isn't possible that some tag part of package will add some dependency? Even I make a bit longer list of problems that I thought at the beginning, I like tag idea. It makes more sense than separating packages. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/desktop-discuss/attachments/20071020/e4d3de80/attachment.html>
