<skvidal> moZer: I saw that, intriguing idea <nasrat> moZer: yeah I saw <jeremy> moZer: although I have to wonder why they don't just give you a repo file instead and then you select what you want to install (and only have to download it) <moZer> well, that would also be possible, but it doesn't cover the case of offline distribution <skvidal> moZer: but offline distribution can just be done with a cd, right? <jeremy> moZer: sure it does... offline distribution is just a cd <moZer> yes, but if the .yar doesn't contain the rpms? <moZer> i mean you can't just put the .repo on a CD <skvidal> then you've just distributed a .repo file, right? <moZer> yes, but you can't install anything without going online <jeremy> moZer: sure you can... we're going to have to have a way to refer to cds anyway <moZer> ok s/offline distribution/offline installation/g <jeremy> moZer: so your repo on a cd basically says "look at cd drives" <moZer> well... <skvidal> or probably more to the point: look for a cd drive with this identifier <jeremy> skvidal: *nod* <Magic8Ball> jeremy: "look at cd if network not there" <skvidal> Magic8Ball: no <Magic8Ball> skvidal: poo <skvidal> Magic8Ball: I don't see a good reason to make it look where you're not telling it to look <skvidal> and code like 'if network not there' has that been written? <moZer> then you'd have a repo file which says "look at cd drives", and a bunch of rpms on the cd <moZer> == a .yar <Magic8Ball> skvidal: i have no idea... im just saying people with needs for install media might have time-dependant needs <skvidal> moZer: then why have the other format? <moZer> it's for downloading as a single file <Magic8Ball> skvidal: depending on availability of the network... and god only knows what a distributor like adobe in moZer example thinks is 'sane' <moZer> that was the idea at least <Magic8Ball> moZer: here's the problem with bundling the rpms with the .repo file <Magic8Ball> moZer: repo overlap <Magic8Ball> moZer: you have absolutely no garuntee that updates will come from the expected repo.. <Magic8Ball> moZer: a .repo file with instructions on which package or group to pull... would allow for the logic of whatever repo collection is configured to resolve itself <moZer> well, that's true <Magic8Ball> moZer: there's no garuntee the rpm payload in a larger archive would actually be used.. if other repos are already configured that have that software <moZer> the target distributor is the ones that don't usually distribute their software in a public repository though <Magic8Ball> moZer: shrug <moZer> and the .repo is optional anyway <Magic8Ball> moZer: i think the .repo is the more important part <Magic8Ball> moZer: i think the rpm payload is optional... for an online download <Magic8Ball> moZer: on a cd... the payload just sits there to be used or not... <Magic8Ball> moZer: for online... who cares when the rpms get downloaded <Magic8Ball> moZer: the .repo and a set of instructions that pup/yum can use to start the install/dep resolution/download process is what matters <Magic8Ball> moZer: as soon as you open the door to outside repos of any nature.. you are opening the door to overlap <moZer> well, the idea isn't to distribute things like gaim like that, which can be found in a number of repositories <moZer> it's mostly for commercial applications <jeremy> moZer: instead of using some archive format, though, why not basically have it be "distribute as an iso"? <nasrat> dmg <moZer> what happens when you try to open an iso in nautilus? <moZer> the format isn't important, the file type assiciation is <moZer> and the fact that it is a single file <Magic8Ball> jeremy: loopback mounting as a normal user is fun <jeremy> Magic8Ball: an iso fs is as easy to grok as a tarball <Magic8Ball> jeremy: hey if you want to teach nautilus to grok it.. great <moZer> still, this idea isn't exactly core business for FC <nasrat> Magic8Ball: archive manager just works <moZer> more like RHEL Home Edition <moZer> :-) <Magic8Ball> nasrat: archive manager doesnt fire off pup does it? <skvidal> moZer: things we work on in FC have a way of finding their way to rhel <Magic8Ball> nasrat: the point is... if you ship it as iso.. something else other than archive manager is gonna have to KNOW to interact with it to start the repo process <Magic8Ball> nasrat: for this specific purpose... archive manager is not what you want opening up <jeremy> Magic8Ball: and if you ship a tarball, then it's just going to open in archive manager and not pup <nasrat> archive manager -> dbus I've found a new repo <Magic8Ball> jeremy: he didnt say ship a tar :-> <Magic8Ball> nasrat: thats great <jeremy> Magic8Ball: same difference for zip file <nasrat> bah ascii cpio all the way <jeremy> nasrat: I wasn't going to say it ;) <Magic8Ball> jeremy: i thought he was suggesting a new file extention <Magic8Ball> jeremy: as a hook <nasrat> we could use xar <jeremy> Magic8Ball: file extensions don't really mean much <Magic8Ball> jeremy: what.. there are no mimetype definitions that are solely file extention based? <jeremy> Magic8Ball: istr all the mime stuff is based more on magic than extensions. hell, "extensions" don't really exist except as vague convention <Magic8Ball> nasrat: if you can make the dbus magic like that work... im all for it <nasrat> Magic8Ball: let me get the first bits finished <Magic8Ball> jeremy: more on.. but im pretty sure there are some that are extention related <Magic8Ball> nasrat: i didnt set a deadline for you :-> <Magic8Ball> nasrat: how about.. before you die...does that work for you? <nasrat> Magic8Ball: will work for donuts <nasrat> or beer <Magic8Ball> nasrat: black doughnuts? <nasrat> with black milk <jeremy> Magic8Ball: mime types are decided based on the mime magic (which is roughly file magic) <moZer> i'll dump this log onto the list, for reference -- Fedora-config-list mailing list Fedora-config-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-config-list