On Sun, Nov 06, 2005 at 05:26:21PM +0100, Sebastian Rother wrote:
> *snip*
> >> Perl and is still buggy. So if you wanna change something then
> >> please take your time...!
> >
> >WHAT is buggy about it ? I haven't seen any recent bug-report.
> >I'm not aware of issues with it.
>
> Dear Marc,
>
Sebastian Rother [Sun, Nov 06, 2005 at 05:26:21PM +0100] wrote:
>godfather $
>perl /usr/ports/infrastructure/build/out-of-date Collecting installed
>packages Collecting port versions:
>complete Collecting port signatures:
>complete Outdated ports:
>
>multimedia/streamdvd # libdvdread-0.9.
*snip*
>> Perl and is still buggy. So if you wanna change something then
>> please take your time...!
>
>WHAT is buggy about it ? I haven't seen any recent bug-report.
>I'm not aware of issues with it.
Dear Marc,
1st: Please send a mail just to me if you've an Off-topic question
2nd: The answer:
On Sat, Nov 05, 2005 at 09:45:56PM +0100, [EMAIL PROTECTED] wrote:
>
> So if you wanna include such a new sheme and if many
> people think it's usefull then do it but do it wisely.
> usr/ports/infrastructure/build/out-of-date was rewritten in
> Perl and is still buggy. So if you wanna change somet
Steve Shockley wrote:
>Another idea, perhaps out of the scope of this discussion,
>is it'd be nice if packages built for one version of the OS
>would refuse to install (by default) on a different version;
>no more "Why do I get this cryptic error message when I try
>to install -current packages on
andrew fresh wrote:
As a 'user' I would like a way to tell easily if a package is for 3.7,
3.8, or current, especially when someone else was supposed to have
upgraded a server.
Another idea, perhaps out of the scope of this discussion, is it'd be
nice if packages built for one version of the O
On Thu, Nov 03, 2005 at 08:35:19PM +0100, Marc Espie wrote:
> On Fri, Nov 04, 2005 at 03:38:50AM +1100, Andrew Dalgleish wrote:
> > On Thu, Nov 03, 2005 at 11:04:35AM +0100, Marc Espie wrote:
> > > On Thu, Nov 03, 2005 at 10:34:21AM +0800, Uwe Dippel wrote:
> > > > If you dared to be radical, you'd
On Thu, Nov 03, 2005 at 08:28:00PM -0800, Marc Matteo wrote:
> How about something that RPM does (or used to do, it's been a while)
> is use an *internal* version number in cases like this. It's
> basically the same thing as the v* idea only it's hidden in the
> Makefile.
>
> So in the gcc
Marc Matteo [Thu, Nov 03, 2005 at 08:28:00PM -0800] wrote:
>How about something that RPM does (or used to do, it's been a while)
>is use an *internal* version number in cases like this. It's
>basically the same thing as the v* idea only it's hidden in the
>Makefile.
>
>So in the gcc case ins
On Thu, 03 Nov 2005 11:04:35 +0100, Marc Espie wrote:
> This does not take care of branch issues...
started to think and don't see this.
File: abiword-2.2.11.tgz8160 KB 01/11/0514:41:00
File: abiword-2.2.9.tgz 8159 KB 04/09/0519:19:00
Why are there
On Nov 2, 2005, at 3:04 PM, Marc Espie wrote:
The main objection you can have is that this is too complicated,
but so
far, we haven't been able to find any hole in that scheme...
Opinions ?
It's too complicated :). Actually it's not, but it'll confuse the
folks adding packages.
How ab
On Thu, 03 Nov 2005 15:49:39 -0700, andrew fresh wrote:
> Human readable, date based serials would be nice as that is something
> easy to recognize and compare. If the serial was human readable, I
> don't think there would be a need for the p* numbers as with the serial,
> you would know which wa
As a 'user' I would like a way to tell easily if a package is for 3.7,
3.8, or current, especially when someone else was supposed to have
upgraded a server. However, I wouldn't like it to have to be a part of
the Makefile as that would be a PAIN to update. So if when packing, it
could look at som
On Fri, Nov 04, 2005 at 03:38:50AM +1100, Andrew Dalgleish wrote:
> On Thu, Nov 03, 2005 at 11:04:35AM +0100, Marc Espie wrote:
> > On Thu, Nov 03, 2005 at 10:34:21AM +0800, Uwe Dippel wrote:
> > > If you dared to be radical, you'd split the name into 3 parts:
> > > generic name - human readable ve
On Thu, Nov 03, 2005 at 11:04:35AM +0100, Marc Espie wrote:
> On Thu, Nov 03, 2005 at 10:34:21AM +0800, Uwe Dippel wrote:
> > If you dared to be radical, you'd split the name into 3 parts:
> > generic name - human readable version - unix time.
> >
> > That would read
> > python-expat-2.3.5-1131013
On Thu, Nov 03, 2005 at 10:34:21AM +0800, Uwe Dippel wrote:
> On Thu, 03 Nov 2005 00:04:15 +0100, Marc Espie wrote:
>
> > Opinions ?
>
> If you dared to be radical, you'd split the name into 3 parts:
> generic name - human readable version - unix time.
>
> That would read
> python-expat-2.3.5-11
> +1 more vote of thanks for really good work on pkg_* - some of us have
> noticed
Here!
The package-system is well written, and the use of Perl-modules makes it
very easy to extend.
Even for an inexperienced programmer like me :-)
Hans
> In order to get you more confused, we've got more bright ideas about
> version numbering...
>
> Right now, we mostly use the `vendor' number scheme, and we add a simple
> p* suffix to denote what's going on with the OpenBSD port.
>
> As we've noticed, some times, vendor version numbers go backwar
On Thu, Nov 03, 2005 at 12:04:15AM +0100, Marc Espie wrote:
The idea is to add some v* suffix each time the numbering scheme changes.
Okay.
Some comments:
- we still need the p* stuff to denote OpenBSD specific changes.
Yes.
- v* versions mean we can go backwards. If we find a security is
* Jolan Luff <[EMAIL PROTECTED]> [051102 20:13]:
> On Thu, Nov 03, 2005 at 12:04:15AM +0100, Marc Espie wrote:
> > In order to get you more confused, we've got more bright ideas about
> > version numbering...
> >
> > Right now, we mostly use the `vendor' number scheme, and we add a simple
> > p* s
On Thu, 03 Nov 2005 00:04:15 +0100, Marc Espie wrote:
> Opinions ?
If you dared to be radical, you'd split the name into 3 parts:
generic name - human readable version - unix time.
That would read
python-expat-2.3.5-1131013320
python-expat: package name
2.3.5: for us humans to know the base ver
On Thu, Nov 03, 2005 at 12:04:15AM +0100, Marc Espie wrote:
> In order to get you more confused, we've got more bright ideas about
> version numbering...
>
> Right now, we mostly use the `vendor' number scheme, and we add a simple
> p* suffix to denote what's going on with the OpenBSD port.
>
> A
In order to get you more confused, we've got more bright ideas about
version numbering...
Right now, we mostly use the `vendor' number scheme, and we add a simple
p* suffix to denote what's going on with the OpenBSD port.
As we've noticed, some times, vendor version numbers go backwards, or we
do
23 matches
Mail list logo
