[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-fs/openafs: openafs-1.4.8_pre2.ebuild
Thanks for pointing this out. I've just updated the ChangeLog now.
Stefaan
2008/10/9 Robin H. Johnson <[EMAIL PROTECTED]>:
> On Wed, Oct 08, 2008 at 09:59:02PM +, Stefaan De Roeck (stefaan) wrote:
>> stefaan 08/10/08 21:59:02
>>
>> Added:openafs-1.4.8_pre2.ebuild
>> Log:
>> Version bump to 1.4.8_pre2
>> (Portage version: 2.2_rc11/cvs/Linux 2.6.26-gentoo x86_64)
> You did not include any ChangeLog entry.
> Please add a ChangeLog entry, and remember to include the sub-header for
> a new ebuild '*${P} (${DATE}' (that header is used for bump detection
> packages.g.o).
>
> (There is a check for this in repoman, it's just not released yet).
>
> --
> Robin Hugh Johnson
> Gentoo Linux Developer & Infra Guy
> E-Mail : [EMAIL PROTECTED]
> GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
>
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-fs/openafs: openafs-1.4.8_pre2.ebuild
On Wed, Oct 08, 2008 at 09:59:02PM +, Stefaan De Roeck (stefaan) wrote:
> stefaan 08/10/08 21:59:02
>
> Added:openafs-1.4.8_pre2.ebuild
> Log:
> Version bump to 1.4.8_pre2
> (Portage version: 2.2_rc11/cvs/Linux 2.6.26-gentoo x86_64)
You did not include any ChangeLog entry.
Please add a ChangeLog entry, and remember to include the sub-header for
a new ebuild '*${P} (${DATE}' (that header is used for bump detection
packages.g.o).
(There is a check for this in repoman, it's just not released yet).
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgp6Cp6etYkIc.pgp
Description: PGP signature
[gentoo-dev] Re: Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
Brian Harring wrote:
> Steve Long wrote:
>> Robert Buchholz wrote:
>> >> Ciaran McCreesh <[EMAIL PROTECTED]> said:
>> >> > "Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
>> >> > > Either we need special cases to declare that it no longer has a
>> >> > > homepage, or we need to allow the empty HOMEPAGE.
>> >> > HOMEPAGE="( )"
>> >> HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/";
>> > Why not use our package site for this, i.e.
>> > HOMEPAGE="http://packages.gentoo.org/package/${CAT}/${PN}";
>> ++ This makes the most sense; it's simple and it enables users to
>> interact with the appropriate channels to get support, or file bugs and
>> patches.
>>
>> If a notice is needed, the website can be amended to state explicitly
>> that upstream is dead (if the homepage points to self.)
>
> Use a constant of some sort rather then having the ebuild hardcode the
> fallback- this shifts the fallback upto the PM (code rather then data
> it operates on) allowing far more flexibility.
>
Sure, so long as the end-user always sees:
"$GENTOO_PKG_URL/package/$CATEGORY/$PN" (or whatever the current schema is)
in the cli, it doesn't matter. The argument would be for someone reading an
ebuild, but I don't think that really matters, as by that time they'd have
got used to seeing the packages url, and it's a one-line comment in the
example file/docs to explain it.
If UNKNOWN or some other non-empty constant is chosen, it's a simple bug to
spot and fix for any externals that don't display it correctly. Have to say
I'd prefer simply allowing empty string in the tree, though. No i18n issue
and it's very well-understood/defined, and seems cleaner (less cruft too.)
Perhaps repoman could allow an empty homepage, but not an unset one?
> An example for why this is a better approach would be if I get really
> really bored some afternoon (or exceedingly drunk) and try to match
> the package back to a freshmeat url when the homepage is
> unknown/unset; using a constant, I can focus on that fun task.
That sounds more like a script-task to me. (plus it doesn't matter how
wasted you are;)
> Use a constant of some sort please, it's way saner from a data format
> standpoint.
>
Agreed.
[gentoo-dev] [project] Re: Re: EAPI-2 and src_configure in eclasses
Ciaran McCreesh wrote: > On Tue, 07 Oct 2008 17:07:21 +0100 > Steve Long <[EMAIL PROTECTED]> wrote: >> > It's illegal, according to PMS. It also won't work with Paludis, >> > since phase function definitions aren't made available until just >> > before that phase executes (there is a reason for this -- it >> > provides us with a way of identifying whether a package has a >> > particular phase or not). >> > >> That seems a bit implementation-specific; how one alternative package >> manager generates that metadata isn't important (though it does seem >> odd that you think it has to be done at that point) nor should it get >> in the way. > > The whole point of PMS is that it provides a way to avoid relying upon > implementation specific things. There are currently no packages that > rely upon calling phase functions in the wrong place It wasn't about calling it in the wrong place, it was about how you test for whether the ebuild+eclasses provide a function, or use a phase. > and there are > good reasons a package manager might want to avoid implementing things > in a way such that doing so is legal, so we don't allow it. > Sure let's keep constraining what the bash side of things can do, as that's nothing to do with the package manager implementation. > Also, I don't think it has to be done at that point. I think it's > convenient to do it at that point, and when combined with several other > reasons doing it that way is the best option. > Yes, a mystery wrapped in an enigma wrapped in pure bullsh^W obfuscation is always such fun. > Strange how you repeatedly seem to pop up in favour of doing whatever > you think will cause most inconvenience to Paludis, though... > Strange how you think you can read my mind.. I actually think that not providing functions an ebuild might call in a phase, during the actual install, is not such a good way for the mangler to ascertain ahead of time whether or not that phase will be needed, *irrespective* of how any extant implementation does it. But as you always remind me, I don't know enough to comment-- because you say so. I actually hesitated to get into that discussion with you. I did so as I wanted to query the design decision. You know, a technical _discussion_.. Thanks for reminding me again how incapable of that you are, unless you think there is some political capital to be gained.
Re: [gentoo-dev] Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
On Tue, Oct 07, 2008 at 12:46:24PM +0100, Steve Long wrote:
> Robert Buchholz wrote:
>
> > On Sunday 05 October 2008, Thilo Bangert wrote:
> >> Ciaran McCreesh <[EMAIL PROTECTED]> said:
> >> > On Sun, 5 Oct 2008 03:44:20 -0700
> >> >
> >> > "Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
> >> > > Either we need special cases to declare that it no longer has a
> >> > > homepage, or we need to allow the empty HOMEPAGE.
> >> >
> >> > HOMEPAGE="( )"
> >>
> >> HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/";
> >
> > Why not use our package site for this, i.e.
> > HOMEPAGE="http://packages.gentoo.org/package/${CAT}/${PN}";
> >
> > i.e. for this particular use case,
> > http://packages.gentoo.org/package/app-mobilephone/smssend
> >
> > The site contains a link to ChangeLog, description, current version,
> > forums and bugs. I would suggest it is the most usable homepage a user
> > can expect if no other exists.
> >
> ++ This makes the most sense; it's simple and it enables users to interact
> with the appropriate channels to get support, or file bugs and patches.
>
> If a notice is needed, the website can be amended to state explicitly that
> upstream is dead (if the homepage points to self.)
Use a constant of some sort rather then having the ebuild hardcode the
fallback- this shifts the fallback upto the PM (code rather then data
it operates on) allowing far more flexibility.
An example for why this is a better approach would be if I get really
really bored some afternoon (or exceedingly drunk) and try to match
the package back to a freshmeat url when the homepage is
unknown/unset; using a constant, I can focus on that fun task.
If the fallback url is hardcoded into the ebuild (data), I wind
up having to know of the url scheme for packages.gentoo.org (both
past and present) to be able to detect if the homagepage is
'unset'; it's both buggy and a pita to try that route.
Use a constant of some sort please, it's way saner from a data format
standpoint.
And no, using a packages.gentoo.org is not constant since the url
namespace can potentially change someday, let alone the idiocy of
having to regex it just to discern 'unset' ;)
~brian
pgpxMgWEzGikv.pgp
Description: PGP signature
[gentoo-dev] One-Day Gentoo Council Reminder for October
This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/
