Gentoo Ebuilds
Alex Brandt
I've made some progress on creating a set of ebuilds for
holland so it can easily be installed on Gentoo systems but I
have a few questions.
First, what is the tarball naming schema used for release
tarballs? Should I just rely on the github exports of the
release tags?
Second, (not meaning to nitpick) why are the configuration
files that go with each plugin not in the plugin directory?
If you'd like to offer some feedback on what I have so far
it's available in this directory:
http://www.alunduil.com/svn/portage/trunk/app-backup.
If anything is blatantly wrong let me know so I can bring it
inline with the accepted standards and practices.
Regards,
--
Alex Brandt
Linux Administrator, RHCE
http://www.alunduil.com
Andrew Garner
> Hello,
>
> I've made some progress on creating a set of ebuilds for
> holland so it can easily be installed on Gentoo systems but I
> have a few questions.
>
> First, what is the tarball naming schema used for release
> tarballs? Should I just rely on the github exports of the
> release tags?
We should always release a holland-${version}.tar.gz tarball. BJ can
comment on this further, but I believe we standardized on releasing to
http://hollandbackup.org/releases/stable/${major_version}/holland-${version}.tar.gz,
where major version is currently 1.0 and the latest official version
is 1.0.2.
> Second, (not meaning to nitpick) why are the configuration
> files that go with each plugin not in the plugin directory?
We also have the global holland.conf in there. The real answer is
just this how things fell together. I suppose there's an argument for
pushing plugin confs to the individual backup plugin directories, but
for the core holland distribution it doesn't make much of a
difference. If we ever split these out and distribute plugins
separately we would certainly have a different layout.
Is this just aesthetics, or does this cause a headache for gentoo deployment?
> If you'd like to offer some feedback on what I have so far
> it's available in this directory:
> http://www.alunduil.com/svn/portage/trunk/app-backup.
>
> If anything is blatantly wrong let me know so I can bring it
> inline with the accepted standards and practices.
Offhand, this looks a little more complex than it needs to be, even
for gentoo. Perhaps someone more familiar with gentoo ebuild
standards can comment.
~Andy
Tim Soderstrom
# emerge holland-mysqldump
And it would pull in your other ebuilds?
I'm pretty sure that was the case but wasn't sure?
> --
> WIKI: http://wiki.hollandbackup.org
> CODE: http://github.com/holland-backup
> UNSUBSCRIBE: holland-deve...@googlegroups.com
>
Alex Brandt
> On Fri, Jul 30, 2010 at 8:11 AM, Alex Brandt
<alun...@gmail.com> wrote:
> > First, what is the tarball naming schema used for release
> > tarballs? Should I just rely on the github exports of the
> > release tags?
>
> We should always release a holland-${version}.tar.gz
tarball. BJ can
> comment on this further, but I believe we standardized on
releasing to
>
http://hollandbackup.org/releases/stable/${major_version}/holland-${version
> }.tar.gz, where major version is currently 1.0 and the
latest official
> version is 1.0.2.
>
Ok, that's what I was assuming but just making sure as I see
the current version on HEAD is set to 1.0.4.
> > Second, (not meaning to nitpick) why are the configuration
> > files that go with each plugin not in the plugin
directory?
>
> We also have the global holland.conf in there. The real
answer is
> just this how things fell together. I suppose there's an
argument for
> pushing plugin confs to the individual backup plugin
directories, but
> for the core holland distribution it doesn't make much of a
> difference. If we ever split these out and distribute
plugins
> separately we would certainly have a different layout.
>
> Is this just aesthetics, or does this cause a headache for
gentoo
> deployment?
Mostly aesthetics and curiosity as it seems like a logical
grouping to place the configuration file for a plugin that is
self-contained inside that plugin.
It also stems from the push I got to make sure each plugin had
it's own ebuild which correlates with the plugin having it's
own source tarball that is self-contained but it's not a big
deal and doesn't cause any headaches for Gentoo deployment.
>
> > If you'd like to offer some feedback on what I have so far
> > it's available in this directory:
> > http://www.alunduil.com/svn/portage/trunk/app-backup.
> >
> > If anything is blatantly wrong let me know so I can bring
it
> > inline with the accepted standards and practices.
>
> Offhand, this looks a little more complex than it needs to
be, even
> for gentoo. Perhaps someone more familiar with gentoo
ebuild
> standards can comment.
>
> ~Andy
Which pieces in particular look complex? I admit that this
was a touch more hackish than I would like but thought I
simplified it fairly well without losing anything important.
If it's alright I'll pass these ebuild upstream to gentoo-dev
and ask for some feedback on the portage standards to make
sure I'm making the best product I can.
Alex Brandt
> Stupid question so I apologize but I forget - Gentoo has
dependency
> tracking right? So I could basically do:
>
> # emerge holland-mysqldump
>
> And it would pull in your other ebuilds?
>
> I'm pretty sure that was the case but wasn't sure?
It does do dependency tracking and the way I implemented it
allows you to simply `emerge holland`. If you need mysql
specifically you make sure the mysql USE flag is set
`USE=mysql emerge holland` and it pulls holland-mysqldump in
for you.
Tim Soderstrom
On Jul 30, 2010, at 4:39 PM, Alex Brandt wrote:
>>
>> We also have the global holland.conf in there. The real
> answer is
>> just this how things fell together. I suppose there's an
> argument for
>> pushing plugin confs to the individual backup plugin
> directories, but
>> for the core holland distribution it doesn't make much of a
>> difference. If we ever split these out and distribute
> plugins
>> separately we would certainly have a different layout.
>>
>> Is this just aesthetics, or does this cause a headache for
> gentoo
>> deployment?
>
> Mostly aesthetics and curiosity as it seems like a logical
> grouping to place the configuration file for a plugin that is
> self-contained inside that plugin.
>
> It also stems from the push I got to make sure each plugin had
> it's own ebuild which correlates with the plugin having it's
> own source tarball that is self-contained but it's not a big
> deal and doesn't cause any headaches for Gentoo deployment.
Yeah that was my bad. I was thinking it would be easier to follow the RPM method there. But for 1st party plugins, it might not matter. Having a way to include/exclude plugins, however, would be something I would recommend. Especially for Gentoo users since they have this thing for not wasting 1MB worth of disk space for packages you don't need :)
So you could combine it all together maybe and do a USE thing?
Really that's up to you there though.
>
>>
>>> If you'd like to offer some feedback on what I have so far
>>> it's available in this directory:
>>> http://www.alunduil.com/svn/portage/trunk/app-backup.
>>>
>>> If anything is blatantly wrong let me know so I can bring
> it
>>> inline with the accepted standards and practices.
>>
>> Offhand, this looks a little more complex than it needs to
> be, even
>> for gentoo. Perhaps someone more familiar with gentoo
> ebuild
>> standards can comment.
>>
>> ~Andy
>
> Which pieces in particular look complex? I admit that this
> was a touch more hackish than I would like but thought I
> simplified it fairly well without losing anything important.
>
> If it's alright I'll pass these ebuild upstream to gentoo-dev
> and ask for some feedback on the portage standards to make
> sure I'm making the best product I can.
It's open source so I would say feel free. If it gets accepted or hosted or whatever, let us know and we can make sure or documentation points to the right place.
Tim
BJ Dierkes
---
derks
Tim Soderstrom
But some people like it dirty so who I am to judge?
Hehe
Alex Brandt
> Yeah that was my bad. I was thinking it would be easier to
follow the RPM
> method there. But for 1st party plugins, it might not
matter. Having a way
> to include/exclude plugins, however, would be something I
would recommend.
> Especially for Gentoo users since they have this thing for
not wasting 1MB
> worth of disk space for packages you don't need :)
>
> So you could combine it all together maybe and do a USE
thing?
>
> Really that's up to you there though.
>
accepted or hosted or
> whatever, let us know and we can make sure or documentation
points to the
> right place.
>
> Tim
I've got the current implementation with the use flags for the
different providers so if someone is already using mysql,
postgres, or sqlite in theory they should already have the use
flag and holland will automagically start working with it.
Putting everything in different ebuilds was a great idea Tim.
I was just razzing you about it a bit. The ready for prime
time builds are now in my overlay
http://www.alunduil.com/alunduil-overlay and if any Gentoo
users want the builds they can add my overlay with layman
using the instructions on that page.