On Thu, 2007-05-03 at 23:43 +0900, Takao Fujiwara wrote: > Probably I need more general rules. > > Do you mean we always put source files in dlc.sun.com whenever the files > just don't have the version number in the filenames without the > dependencies of the license?
Well, the general rule is that we use dlc.sun.com for source downloads when the source tarball that is not (or not reliably) available from the original download site. We also use dlc.sun.com for sources that originate from Sun. > If we use dlc.sun.com instead of the original URL, how do users download > the original source files in community? That's the point: dlc.sun.com is on the internet so it's accessible both inside and outside Sun. Laca > fujiwara > > Laszlo (Laca) Peter wrote: > > On Thu, 2007-05-03 at 17:20 +0900, Takao Fujiwara wrote: > >> Laszlo (Laca) Peter wrote: > >>> On Wed, 2007-05-02 at 19:58 +0900, Takao Fujiwara wrote: > >>>> Let's say the next deadline is 20:00 today @Dubline time. > >>>> The AIs are to: > >>>> - replace http://.../foo.zip with > >>>> http://.../foo%{?!_with_download:-YYYY-MM-DD}.zip to follow > >>>> http://wiki.services.openoffice.org/wiki/Dictionaries > >>>> - remove en_US.aff since GNOME applications cannot use it. > >>>> - deliver all documents in _doc dir beside README* files. > >>> Hmm... Keep in mind that the default behaviour should "just > >>> work". I.e., people shouldn't need to use --with-download > >>> in order to get an url that works. > >> I'ld like to hack pkgtool. When we give "download" argument, it defines > >> "_with_download". > >> > >> Do you have any ideas? > >> If I added '$defaults->define ('_with_download', '1');' or 'process_with > >> ("with", "download");' in pkgtoo.pl, it does not define the parameter. > > > > I agree with Damien that this is not a good idea. > > --download should download whatever the url is and not rewrite the > > url to something that can be downloaded. > > > >>> If we change the file names, we should upload the renamed > >>> files to dlc.sun.com and set the Source urls to point there. > >> Sorry, I don't understand this exactlly. > >> Could you please explain your concerns with detail? > >> The two files foo.zip and foo-versoin.zip are the same files and > >> checksums are same. > >> The zip%{?!_with_download:-date}.zip means the .spec works with both > >> foo.zip and foo-version.zip. > >> All I understand is the RE needs the version numbers for the internal > >> builds. > > > > Damien explained this too. > > We have space here: > > http://dlc.sun.com/osol/jds/downloads/extras/ > > > > I suggest we create a subdir under this, e.g. myspell and > > upload the versioned tarballs there. > > Then set the Source urls in the spec file to that url. > > > > Laca > > > >>> But hey, isn't openoffice.org another project related to Sun? > >>> Can we just ask them to use versioned tarballs like any well > >>> behaved software? > >> Yes, you're right but it seems currently StarOffice team does not work > >> on the dict packages when we discussed so lively and we GNOME l10n team > >> has generates this package. It seems we need to convince each maintainer > >> by dict language. > >> At the moment, I think the _with_download parameter is the instant > >> solution and it takes a long span to covince each maintainer. > >> > >> fujiwara > >> > >>> Laca > >>> > >>>> If you have no time, I'll do that. > >>>> > >>>> Thanks, > >>>> fujiwara > >>>> > >>>> Takao Fujiwara wrote: > >>>>> I wonder why you could change the owner. I think the implementation of > >>>>> 80% are comming from myself and note I have been on vacation since > >>>>> Saturday. > >>>>> > >>>>> Thanks, > >>>>> fujiwara > >>>>> > >>>>> Yuriy Kuznetsov wrote: > >>>>>> Dermot, > >>>>>> > >>>>>> Dermot McCluskey wrote: > >>>>>> > >>>>>>> Yuriy, > >>>>>>> > >>>>>>>> Sorces of dictionaries were taken from community and their locations > >>>>>>>> are correct in Source section of SUNWmyspell-dictionary.spec on the > >>>>>>>> moment of creation of SUNWmyspell-dictionary-* pkgs. > >>>>>>> > >>>>>>> So my question is, are these external files likely to be overwritten > >>>>>>> by their communities, so that, for example, we could not > >>>>>>> reproduce a specific historical build because only the new > >>>>>>> source tarballs are now available? > >>>>>> We thought it would be a good idea to keep names as they are in > >>>>>> community. > >>>>>> > >>>>>>> Will you be putting copies of these tarballs in the internal > >>>>>>> tarball repository (I don't see them there currently)? > >>>>>> Yes. > >>>>>> > >>>>>>> Maybe you could unzip and rezip them with a version when doing so? > >>>>>> We probably can do this way. > >>>>>> Fujiwara, what do you think about this issue ? > >>>>>> > >>>>>>> Also, copyright year (and owner?) in the header seem incorrect. > >>>>>> Made correction(file attached). > >>>>>> > >>>>>> Thanks, > >>>>>> yuriy > >>>>>> > >>>>>>> - Dermot > >>>>>>> > > >
