Re: [Freemint-discuss] RPMint

[Paul W. <pau...@gm...>]

This sounds great, and nice to see previous work has not gone to waste

Having spec's and patches on github would be a bonus too, and for your
project (server) you could keep a local repo so updates are not bulk
downloads, but you can also pull raw files too

I would ask to find a location on the net to provide alternate/backup
for finalized SRPM/RPM, a location that is going to be around for
years to come, in case for some reason you net/server/app is not
available in the future. This also supports installs not having to do
a  dist-upgrade just to get a usable SRPM/RPM for that install. And it
would support distro mirror in the southern hemisphere (and/or
european mirrors) (mostly for speed)

To that end, github allows binary package releases (placed on a
seperate repo obviously), and sourceforge has php and "project web
space". There is no reason why both GH & SF could not be employed to
support redundancy and assist web frontends.

I support adding cross-build at a later date, at least to the point
where your app is working 100% for native builds, at least then
someone else can work on the cross-build as well (if need be)

To help support native builds and possibly improve speed and resource
use, I have asked on the ARAnyM list re:CLI (non-gui) version of
ARAnyM. I hope that will produce some results too, as it has the
potential to affect gui versions for possible (input) scripting later
on

With this project, someone else would be able to supply a "distro
image" as well, which would be useful for Native AtariST, not just
ARAnyM (esp. on RPi)

Cheers, looking forward to the results

Paul


On 1/26/18, Mark Duckworth <mdu...@at...> wrote:
> In principle I agree with this but in practice I wonder how it would
> work with RPM's opinionated ways.  To generate an SRPM file which is the
> theoretical input to such a project, RPM basically demands the source
> files, patches, and a spec file and the whole thing has to build
> successfully.   If it does, it will create the SRPM along with the final
> package.  The utility there, at least for me, is that if you manage to
> get an SRPM file you've probably assembled it all properly.   Someone
> would upload an SRPM file which contains everything and the autobuilder
> would take it from there.  No doubt we will have libraries that will
> break other packages taht depend on it, so we'll have to have some trial
> mechanism that demands a successful build of dependent packages before
> the new one replaces anything.
>
> It wouldn't be the end of the world to forgo that and instead trust the
> specs that people upload are well tested.  And lets be realistic here,
> there will be very few people actually contributing.  The problem there
> is that there would be a ton of binary content on github.  You know the
> .tar.gz source files for packages.  Not a well advised idea and a git
> pull would slowly get insanely huge.  I think this is what is going on
> with cocoapods which can take a long time to sync.
>
> Alternatively, you could store only patches and specs github and source
> code on rpmint ftp.  The spec could reference the source url on the
> rpmint server (I would insist on having a local copy as we tend to get
> far behind other systems in versions).  This isn't an awful idea as in
> theory the source archive should be the same (and should validate with
> md5 or sha1 sum).  It looks like there are tools that will download
> source from an input spec file.
>
> https://stackoverflow.com/questions/33177450/how-do-i-get-rpmbuild-to-download-all-of-the-sources-for-a-particular-spec
>
> So I can use github to the extent that patches and specs are stored
> there.  The question is, is the purpose of the autobuilder to vet
> people's raw source changes (autobuild on hook from spec/patch commit),
> or is the purpose to submit a well vetted prebuilt SRPM and get back out
> optimized versions for coldfire, 68020 and 68000.  I think the latter is
> for me.
>
>
> On 01/25/2018 05:13 PM, Miro Kropáček wrote:
>>
>>
>
>> What I would recommend here is to open a github repository which would
>> contain package sources and setup git hooks to your server -- that way
>> it's super easy to contribute/fix packages and you can focus solely on
>> the building part & GUI for downloading/searching etc. In fact, this
>> (the need to have an own server if you want to track build dependencies)
>> is the only reason why we already don't have this in FreeMiNT (so you
>> can't push a change to, say, gemlib and get freemint's tools rebuilt).
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>