Packaging "More"
BKLive
1) remember all the details about making .deb and .rpm packages
2) package up 0.1.1 (or the 0.2.rc1) in these alternate package
formats
3) run kubuntu (or crunchbang) in qemu to test the .deb
4) run fedora 13 in qemu (or maybe vb) and test the .rpm
Which, honestly, shouldn't take much more time than creating the
packages since testing will be fairly quick and efficient since I'll
be in the 'host' OS already to make the packages. Once I'm done with
these I'll let you know how it goes and email you the final products
if they're 100%, or post them to this discussion as attachments (won't
be big files, as you know). This issue that might come up with this is
package maintenance being a branch of issue handling. Package X.deb
doesn't install without breaking Y feature on Z system. These types of
things. Not to mention that the .rpm might have snags in
different .rpm distros outside of Fedora (not that I'd use any of
those, but other people might).
So then I wonder if hosting these packages on your site would be
beneficial or putting the .deb in a "ppa" repo (like ubuntu uses), or
a private repo for Fedora/RPM outside of the project homepage? Both of
these ideas would work, but the issue I would like to avoid is people
having problems with installing from the .rpm and submitting an issue
to the project site instead of me (the package maintainer). This is
really a moot issue in Arch because the AUR is set up for this,
specifically (much like Zenwalk uses the ZUR, a super cool clone, btw)
to submit issues to me through the comment chains on the hosted
package site.
Something to think about. I should have the .deb packages done by
tomorrow evening-ish because I'll be working this first (Fedora is
having issues with qemu).
BKLive
correctly and it's feeding me a lot of "errors" in compilation which
is probably due to a gcc dependency issue, which I cannot resolve due
to massively slow internet through vbox. On top of that, my Fedora
Live disc I took 24 hours to download (like a week ago) failed md5sum
checks so I cannot use it.
This project will be put on hold for a bit until I can get my hands on
super fast internet and my other laptops which run the other two
required OS's.
More later,
BKL
William Diem
From: William Diem <wmd...@gmail.com>
Date: 5 August 2010 13:42
Subject: Re: [euclid-wm:50] Re: Packaging "More"
To: BKLive <benjami...@gmail.com>
> On Aug 5, 2:26 am, BKLive <benjamin.ku...@gmail.com> wrote:
>> So then I wonder if hosting these packages on your site would be
>> beneficial or putting the .deb in a "ppa" repo (like ubuntu uses), or
>> a private repo for Fedora/RPM outside of the project homepage?
I know this is a moot point right now, but yes putting distro packages
on the googlecode site would not be an issue. Putting them into some
sort of official repository would be best, putting them into an
unofficial repository (the kind that the user would need to explicitly
add) would be good, if possible.
I had looked into all three of these possibilities, and had basically
decided that the cost/benefit analysis favored either a stand-alone
package with no repository, that would be downloaded directly from the
site (because it is the easiest option), or the "official" repository
(more work, but lots of advantages, like easy upgrades, high
visibility, and so on). But that was a tentative conclusion, a PPA or
something like it might be a perfectly good option.
On 5 August 2010 12:57, BKLive <benjami...@gmail.com> wrote:
> Funny thing about this: not doing it. I am doing the deb instructions
> correctly and it's feeding me a lot of "errors" in compilation which
> is probably due to a gcc dependency issue, which I cannot resolve due
> to massively slow internet through vbox. On top of that, my Fedora
> Live disc I took 24 hours to download (like a week ago) failed md5sum
> checks so I cannot use it.
>
> This project will be put on hold for a bit until I can get my hands on
> super fast internet and my other laptops which run the other two
> required OS's.
I'm sorry to hear you had trouble. Thanks for giving it a go though.
Just for the record, this is what I had been reading:
http://www.debian.org/doc/maint-guide/ initially when I looked into
this.
It is the maintainer's guide for debian packages (i.e., packages
available through the debian repositories).
I think the basic process is setting up a bunch of stuff locally,
uploading it all to debian servers, and the package itself is built
there, in a controlled environment. Advantages: 1) Theoretically
trivial to update once it is setup, 2) makes the package available
through apt. 1) Disadvantages, it looks like a pain to setup, 2) I
suspect it has a fairly long turn around.
>
> More later,
> BKL
Do keep me posted if you decide to come back to it.
Will