Florent Daigni?re skrev: > * Zero3 <zero3 at zerosplayground.dk> [2008-12-12 02:28:18]: > > >> Florent Daigni?re skrev: >> >>> * Zero3 <zero3 at zerosplayground.dk> [2008-12-12 01:48:40]: >>> >>> >>> >>>> Florent Daigni?re skrev: >>>> >>>> >>>>> * Zero3 <zero3 at zerosplayground.dk> [2008-12-11 19:18:30]: >>>>> >>>>> >>>>> >>>>>>> Disadvantages: >>>>>>> - Have to do some work on emu. >>>>>>> >>>>>>> >>>>>>> >>>>> That alone is a good reason why *not* to do it. I don't see why >>>>> installers should be auto-built nor built from emu for that matter. >>>>> >>>>> >>>>> >>>> Investing time is a necessary cost for doing anything new. You won't get >>>> far without investing time in something... >>>> >>>> >>>> >>> True but NEW doesn't imply it's BETTER or even GOOD. >>> >>> >> Good, then we agree - toad posted the list of advantages and >> disadvantages earlier. >> >> >>> >>> >>>> Building the installers on emu seems like the most logical thing to me? >>>> Packaging the files the same place they are compiled seems like a good >>>> approach. >>>> >>>> >>>> >>> It doesn't to me, for several reasons. The major two are: >>> 1) Installers have to be signed by 3rd parties because they are >>> the means we use to bootstrap the trust-chain... And we don't want devs >>> to store their private keys on emu. >>> 2) Here you are talking about building a native installer from a >>> different platform. It's way from being a straightforward operation... >>> and even though it might be doable in this instance, we can't expect it to >>> be doable in any case. >>> >>> >> 1) And they cannot be signed in the same way the bins are atm.? >> >> > > No. > > I'm fed up with repeating over and over the same things. The way builds > are signed atm sucks. Matthew is using his private, unsigned and untrusted > key (which he shouldn't store on emu anyway) to sign them. > > A while ago we had an argument about whether to use a signed or a > non-signed key and finally I gave up and got a trusted signed key... Which I > used to sign the installer. Then toad wanted me to store it on emu so > that he could use it... Of course I objected and finally gave up too... > All was like that until recently. Now the installer is signed using a > non-signed, non-trusted key belonging to matthew and hosted on emu (yay, > YetAnotherRegression). > >
I'm not really trying to discuss how the builds should be signed (another discussion really), but trying to figure out why you can sign the compiled .jars, but not the compiled .exe installer? >> 2) The topic wasn't really about which platform to pack on, but if to >> build and pack on the same platform. It isn't preferred to build >> applications for platform A on platform B, but since we have 1 emu, >> which runs platform B, we will have to do with that. AHK is supported by >> Wine, which runs on Linux, so I don't really see the big problem >> (besides spending time installing Wine, which we already have an >> argument going on about) >> >> > > You are thinking about your installer here and not others. Tomorrow > sanity will want his macos installer to be built there too; how do you > do that? What about win64? ... > So because we have the possibility to do improvements for one platform, we shouldn't - because we might not be able to do so for all the other platforms? I'd say thats a poor policy. I think it is just fine to use native installers where possible, and fall back to a generic for platforms we cannot support with native installers (or packages, or dmg files or whatever). > >>> >>> >>>>>> I'd argue that most >>>>>> coders can figure out how AHK works quite easily though. There are a >>>>>> bunch of examples on the AHK site (e.g. >>>>>> http://www.autohotkey.com/docs/scripts/VolumeOSD.htm) if anyone is >>>>>> interested. >>>>>> >>>>>> >>>>>> >>>>> We all have soooo much free time on our hands that we would eager learn >>>>> that new, windows-only technology. Oh, and that's also why we do have a >>>>> native windows installer since before 0.7 started too btw. >>>>> >>>>> >>>>> >>>> Can't we drop the sarcastical tone for once, please? >>>> >>>> >>>> >>> What am I supposed to do here? The three options I see are >>> - ignoring you for good, even on the mailing lists >>> - being sarcastic >>> - cry, depress and eventually get drunk enough to forget about the >>> stupid technical solutions proposed. >>> >>> >>> >> What about: >> 4) Be mature and discuss the subject in a proper manner for the greater >> benefit of Freenet >> >> > > That's what I have tried to do until now but I will eventually give up. > > I happen to be familiar with both the installation-related issues and > the infrastructure ones and that's why the debate is mostly in between > you and me. The catch is that I am not willing to spend time on it; I am > not interested by native installers anymore. > > If I look back at the discussions we've had the last couple of weeks, I'd say you have been acting like that from the start of. Hell, even back when I wrote the Windows update script I met the same attitude. Good thing that other people can look into it when you don't want to, then. >> I'm not throwing sarcastic comments at you just because I don't agree >> with you. >> > > Most of the questions you are asking have already been asked, debated > and answered in the past. I am pissed to see that the project is doing > over and over the same mistakes. > > We spent *days* on endless debates, eventually found a conclusion but are > going to do it again over the exact same issues whereas nothing has changed. > > I don't recall we found conclusions to all the problems? Unless you are referring to discussions without me? I don't suppose toad would have posted those mails in the first place, if we already had found the best solutions? >> It would be nice if you was willing to communicate on the same >> terms. >> >> > > I am not preventing you from using the sarcastical tone. > > I know, but I'm not willing to. I think it's much better to communicate on a mature plan without the need of things like sarcastic comments when you don't agree with eachother. - Zero3
