Prev: Newer autoconf (2.63+)?
Next: Silent distfiles conflict between graphics/xface.el andmail/x-face-e21.
From: eculp on 29 Mar 2010 18:57
Quoting Ivan Voras <ivoras(a)freebsd.org>:

> Doug Hardie wrote:
>> On 29 March 2010, at 08:57, Ivan Voras wrote:
>>
>>> In some cases the burdens are obvious - the maintainer(s) would need to
>>> e.g. maintain three versions of the ports - a random example would be
>>> e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be
>>> keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future
>>> (CURRENT/9.x) branch.
>>
>> I am a bit concerned about your concept of maintain, being able to
>> build a port successfully, does not necessarily mean it will work
>> properly. For example, qpopper (which I maintain) has an issue
>> where one feature does not work properly on 64 bit machines where
>> it works fine on 32 bit machines. In addition, there are a number
>> of other machine types that are currently not heavily used but
>> might become so in the future. Thats a lot of different
>> combinations of hardware and OSs to keep running for the maintainers.
>
> It was done (in Linux), hence it can be done. If all else fails and
> both the project and the maintainer cannot find suitable build and
> test machines, I'd suggest using ONLY_FOR_ARCHS, or doing the whole
> "stable" dance only for Tier 1 platforms (enumerated in
> http://www.freebsd.org/doc/en/articles/committers-guide/archs.html
> to be i386, amd64, pc98). AFAIK from the ports POW, pc98 and i386
> are too close to be considered separately.
>
> Virtualization (VirtualBox) may help maintainers test on the
> architecture they don't run natively.

IIRC, pcbsd uses both ports and package system that I have assumed was
similar to linux but I have never used it so I can't comment but it
would seem practical to work together if there is common ground. Their
site says:
--
The PBI Format

Part of making a Desktop Operating System that people feel immediately
comfortable with is ensuring that software installation is as easy and
familiar as possible. PC-BSD has taken this approach when developing
the PBI (Pc-Bsd Installer or Push-Button Installer) file format.
Programs under PC-BSD are completely self-contained and
self-installing, in a graphical format. A PBI file also ships with all
the files and libraries necessary for the installed program to
function, eliminating much of the hardship of dealing with broken
dependencies and system incompatibilities. PBI files also provide
developers and packagers with advanced scripting and user interaction
in an entirely graphical format, making the entire install procedure
similar to what a user would expect from other popular graphical
operating systems.
--

I personally like the way the ports work and will probably not change
to any type of packages but you never know. I have never felt
comfortable with the Linux packages.

Have a great day,

ed



_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Dominic Fandrey on 30 Mar 2010 02:18
On 29/03/2010 17:57, Ivan Voras wrote:
> One way to do it, my proposal, would be to maintain a stable "overlay"
> of the ports, one for each major supported branch (i.e. 6.x, 7.x, 8.x),
> containing ports deemed "important" for some reason.

Who would be doing the additional work? I figure we'd need
additional maintainers for the different branches.

I don't see myself maintaining several branches of my ports, apart
from ioquake3 and ioquake3-devel.

Regards

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Garrett Cooper on 30 Mar 2010 03:06
On Mon, Mar 29, 2010 at 3:57 PM, eculp <eculp(a)encontacto.net> wrote:
> Quoting Ivan Voras <ivoras(a)freebsd.org>:
>
>> Doug Hardie wrote:
>>>
>>> On 29 March 2010, at 08:57, Ivan Voras wrote:
>>>
>>>> In some cases the burdens are obvious - the maintainer(s) would need to
>>>> e.g. maintain three versions of the ports - a random example would be
>>>> e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be
>>>> keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future
>>>> (CURRENT/9.x) branch.
>>>
>>> I am a bit concerned about your concept of maintain, being able to build
>>> a port successfully, does not necessarily mean it will work properly.  For
>>> example, qpopper (which I maintain) has an issue where one feature does not
>>> work properly on 64 bit machines where it works fine on 32 bit machines..  In
>>> addition, there are a number of other machine types that are currently not
>>> heavily used but might become so in the future.  Thats a lot of different
>>> combinations of hardware and OSs to keep running for the maintainers.
>>
>> It was done (in Linux), hence it can be done. If all else fails and both
>> the project and the maintainer cannot find suitable build and test machines,
>> I'd suggest using ONLY_FOR_ARCHS, or doing the whole "stable" dance only for
>> Tier 1 platforms (enumerated in
>> http://www.freebsd.org/doc/en/articles/committers-guide/archs.html to be
>> i386, amd64, pc98). AFAIK from the ports POW, pc98 and i386 are too close to
>> be considered separately.
>>
>> Virtualization (VirtualBox) may help maintainers test on the architecture
>> they don't run natively.
>
> IIRC, pcbsd uses both ports and package system that I have assumed was
> similar to linux but I have never used it so I can't comment but it would
> seem practical to work together if there is common ground. Their site says:
> --
> The PBI Format
>
> Part of making a Desktop Operating System that people feel immediately
> comfortable with is ensuring that software installation is as easy and
> familiar as possible. PC-BSD has taken this approach when developing the PBI
> (Pc-Bsd Installer or Push-Button Installer) file format. Programs under
> PC-BSD are completely self-contained and self-installing, in a graphical
> format. A PBI file also ships with all the files and libraries necessary for
> the installed program to function, eliminating much of the hardship of
> dealing with broken dependencies and system incompatibilities. PBI files
> also provide developers and packagers with advanced scripting and user
> interaction in an entirely graphical format, making the entire install
> procedure similar to what a user would expect from other popular graphical
> operating systems.
> --
>
> I personally like the way the ports work and will probably not change to any
> type of packages but you never know.  I have never felt comfortable with the
> Linux packages.

From what I've heard PBIs actually resemble OSX's dmgs more than
Linux packages as Linux doesn't package in `bundle' format (contain
all of the needed applications and libraries in one container).
HTH,
-Garrett
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Garrett Cooper on 30 Mar 2010 03:21
On Mon, Mar 29, 2010 at 12:49 PM, Ivan Voras <ivoras(a)freebsd.org> wrote:
> Doug Hardie wrote:
>>
>> On 29 March 2010, at 08:57, Ivan Voras wrote:
>>
>>> In some cases the burdens are obvious - the maintainer(s) would need to
>>> e.g. maintain three versions of the ports - a random example would be
>>> e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be
>>> keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future
>>> (CURRENT/9.x) branch.
>>
>> I am a bit concerned about your concept of maintain, being able to build a
>> port successfully, does not necessarily mean it will work properly.  For
>> example, qpopper (which I maintain) has an issue where one feature does not
>> work properly on 64 bit machines where it works fine on 32 bit machines.  In
>> addition, there are a number of other machine types that are currently not
>> heavily used but might become so in the future.  Thats a lot of different
>> combinations of hardware and OSs to keep running for the maintainers.
>
> It was done (in Linux), hence it can be done. If all else fails and both the
> project and the maintainer cannot find suitable build and test machines, I'd
> suggest using ONLY_FOR_ARCHS, or doing the whole "stable" dance only for
> Tier 1 platforms (enumerated in
> http://www.freebsd.org/doc/en/articles/committers-guide/archs.html to be
> i386, amd64, pc98). AFAIK from the ports POW, pc98 and i386 are too close to
> be considered separately.
>
> Virtualization (VirtualBox) may help maintainers test on the architecture
> they don't run natively.

Virtualbox only runs x86-compatible platforms:

An x86 virtualization software package developed by Sun Microsystems.
Distributed under either the GNU GPL or a proprietary license with
additional ...

That would leave arm, ia64, mips, powerpc, and sparc64 out in the
cold. Maybe folks should try qemu (despite the fact that it's a
buggy-ish emulator?):

>From <http://wiki.qemu.org/download/qemu-doc.html>:

For system emulation, the following hardware targets are supported:

* PC (x86 or x86_64 processor)
* ISA PC (old style PC without PCI bus)
* PREP (PowerPC processor)
* G3 Beige PowerMac (PowerPC processor)
* Mac99 PowerMac (PowerPC processor, in progress)
* Sun4m/Sun4c/Sun4d (32-bit Sparc processor)
* Sun4u/Sun4v (64-bit Sparc processor, in progress)
* Malta board (32-bit and 64-bit MIPS processors)
* MIPS Magnum (64-bit MIPS processor)
* ARM Integrator/CP (ARM)
* ARM Versatile baseboard (ARM)
* ARM RealView Emulation/Platform baseboard (ARM)
* Spitz, Akita, Borzoi, Terrier and Tosa PDAs (PXA270 processor)
* Luminary Micro LM3S811EVB (ARM Cortex-M3)
* Luminary Micro LM3S6965EVB (ARM Cortex-M3)
* Freescale MCF5208EVB (ColdFire V2).
* Arnewsh MCF5206 evaluation board (ColdFire V2).
* Palm Tungsten|E PDA (OMAP310 processor)
* N800 and N810 tablets (OMAP2420 processor)
* MusicPal (MV88W8618 ARM processor)
* Gumstix "Connex" and "Verdex" motherboards (PXA255/270).
* Siemens SX1 smartphone (OMAP310 processor)
* Syborg SVP base model (ARM Cortex-A8).
* AXIS-Devboard88 (CRISv32 ETRAX-FS).
* Petalogix Spartan 3aDSP1800 MMU ref design (MicroBlaze).

Thanks,
-Garrett
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Ivan Voras on 30 Mar 2010 04:49
On 30 March 2010 09:30, Garrett Cooper <yanefbsd(a)gmail.com> wrote:

> Sorry -- one last thing to kick around before I get off this topic:
>
> If this is really slick and tinderbox / whatever tools is doing its
> job and no PRs have been reported for X number of days on a given port
> (would require tie-ins to GNATS, or whatever), perhaps it would be
> nice if ports were automatically `promoted' from HEAD to STABLE? I
> mean, why do something if a computer can do it for you, right :)?

No, not really - what if the new port contains a version bump?

I don't consider "stable" as in "builds and works" good enough, it
really needs to be kept in a sane state with regards to version bumps,
shared libs bumps, etc.
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Newer autoconf (2.63+)?
Next: Silent distfiles conflict between graphics/xface.el andmail/x-face-e21.