Re: continuing conversation from UDS-N - Application Review Board

[Barry Warsaw]

On Nov 17, 2010, at 11:35 AM, Philipp Kern wrote:

>FWIW (and I didn't see this raised in this thread) FQDNs do not need to be
>registered with the LANANA and can be used instead of a registered string
>(see [1]).  So if you distribute the packages through extras.ubuntu.com
>anyway, it might make sense to reuse the same name here.

+1

-Barry


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Barry Warsaw]

On Nov 15, 2010, at 05:53 PM, Allison Randal wrote:

>> Sure, but this is the "consenting adults" argument.  The thing is, the
>> packages are going to be available in either case, so you're just putting an
>> inconvenient sys.path hack in front of anyone who really wants to do it.
>
>The tricky thing is, we're wrapping lightweight apps in an inconvenient 
>sys.path hack (to make it difficult to get to application-specific 
>libraries, for security and isolation) AND trying to make it easy for 
>new developers at the same time. The tools just aren't up to the job yet.

Right, and as I mentioned in my OP, I think it's entirely appropriate for the
apps we're talking about here to use private module paths.

I just think that for normal Ubuntu applications, it's largely an unneeded
separation.  One valid use case though would be if an application does not
actually put its supporting code in a library.  Then there's no package
namespace umbrella that would get installed under dist-packages, so dropping
it in a private area and twiddling sys.path makes sense.

As an example, look at update manager.  It has a package called UpdateManager
which contains a bunch of support code.  Other than the old skool non-pep8
package name, I see no reason why this would have to be tucked away in a
private location.  It's not likely that the package name will collide with
anything, so seems fairly safe to put in the standard dist-packages location.

But since this is embodied in Debian Python policy, this is probably not the
forum, and definitely not the thread, to discuss it.  Sorry for the noise.

-Barry


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Scott Kitterman]

On Thursday, November 18, 2010 12:51:40 pm Allison Randal wrote:
> On 11/18/2010 09:22 AM, Martin Pitt wrote:
> > Philipp Kern [2010-11-17 11:35 +0100]:
> >> FWIW (and I didn't see this raised in this thread) FQDNs do not need to
> >> be registered with the LANANA and can be used instead of a registered
> >> string (see [1]).  So if you distribute the packages through
> >> extras.ubuntu.com anyway, it might make sense to reuse the same name
> >> here.
> > 
> > I think that's a nice idea. It avoids namespace collisions (with host
> > names being unique), and denotes more clearly where they come from.
> 
> Sounds like a winner, any objections? If not, I'll modify the proposal
> to use /opt/extras.ubuntu.com/, to be discussed at the next TB.
> 
> Allison

I did check to see if it should be extras.ubuntu.com or com.ubuntu.extras and 
that looks like the correct form:

http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-
generic/pkgnameconv.html

I think this is the best option.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Allison Randal]

On 11/18/2010 09:22 AM, Martin Pitt wrote:
> Philipp Kern [2010-11-17 11:35 +0100]:
>> FWIW (and I didn't see this raised in this thread) FQDNs do not need to be
>> registered with the LANANA and can be used instead of a registered string
>> (see [1]).  So if you distribute the packages through extras.ubuntu.com
>> anyway, it might make sense to reuse the same name here.
>
> I think that's a nice idea. It avoids namespace collisions (with host
> names being unique), and denotes more clearly where they come from.

Sounds like a winner, any objections? If not, I'll modify the proposal 
to use /opt/extras.ubuntu.com/, to be discussed at the next TB.

Allison

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Luke Faraone]

On 11/18/2010 12:21 PM, Martin Pitt wrote:
> I'd just call it /opt/appname, but I could live with /opt/extras/appname.

Per
,
folder names in /opt/ MUST be a package or a provider name registered
with LANANA to avoid conflicts, excepting TLDs.

Therefore, /opt/extras.ubuntu.com/ would require no additional action on
our part, or we could request registration of "extras-ubuntu" /
"ubuntu-extras".

-- 
╒═╕
│Luke Faraone  ╭Debian / Ubuntu Developer╮│
│http://luke.faraone.cc╰Sugar Labs, Systems Admin╯│
│PGP: 5189 2A7D 16D0 49BB 046B  DC77 9732 5DD8 F9FD D506  │
╘═╛



signature.asc
Description: OpenPGP digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Martin Pitt]

Philipp Kern [2010-11-17 11:35 +0100]:
> FWIW (and I didn't see this raised in this thread) FQDNs do not need to be
> registered with the LANANA and can be used instead of a registered string
> (see [1]).  So if you distribute the packages through extras.ubuntu.com
> anyway, it might make sense to reuse the same name here.

I think that's a nice idea. It avoids namespace collisions (with host
names being unique), and denotes more clearly where they come from.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Martin Pitt]

Allison Randal [2010-11-16 11:21 -0800]:
> - They suggested /opt/ubuntu/ instead of /opt/extras/ 
> as the private install location,

For the record, I didn't (someone else might have, I don't remember
any more). We went through some lengths to explicitly not call those
part of Ubuntu. 

I'd just call it /opt/appname, but I could live with /opt/extras/appname.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Philipp Kern]

On Wed, Nov 17, 2010 at 10:31:13AM +, Colin Watson wrote:
> On Tue, Nov 16, 2010 at 07:44:24PM +, Shane Fagan wrote:
> > On Tue, 2010-11-16 at 11:38 -0800, Rick Spencer wrote:
> > > Does "/opt/ubuntu/" perhaps suggest a bit of "officialness" or support
> > > from the Ubuntu community, whereas these apps are specifically *not*
> > > suppose to have such a connotation? 
> > Yeah I get what Rick is saying here. Does using /opt/ubuntu imply that
> > these apps are officially supported in some capacity? I think it does a
> > little, id say /opt/extra is a better option.
> We don't own the /opt namespace, so "extra" is far too general.  See
> http://www.lanana.org/lsbreg/providers/providers.txt for the kinds of
> names that are suitable there.
> 
> "ubuntu-extras" would be fine, I imagine, and connotes exactly as much
> support as "extras.ubuntu.com" does.

FWIW (and I didn't see this raised in this thread) FQDNs do not need to be
registered with the LANANA and can be used instead of a registered string
(see [1]).  So if you distribute the packages through extras.ubuntu.com
anyway, it might make sense to reuse the same name here.

Kind regards
Philipp Kern

[1] http://www.lanana.org/lsbreg/providers/index.html


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Colin Watson]

On Tue, Nov 16, 2010 at 07:44:24PM +, Shane Fagan wrote:
> On Tue, 2010-11-16 at 11:38 -0800, Rick Spencer wrote:
> > Does "/opt/ubuntu/" perhaps suggest a bit of "officialness" or support
> > from the Ubuntu community, whereas these apps are specifically *not*
> > suppose to have such a connotation? 
> 
> Yeah I get what Rick is saying here. Does using /opt/ubuntu imply that
> these apps are officially supported in some capacity? I think it does a
> little, id say /opt/extra is a better option.

We don't own the /opt namespace, so "extra" is far too general.  See
http://www.lanana.org/lsbreg/providers/providers.txt for the kinds of
names that are suitable there.

"ubuntu-extras" would be fine, I imagine, and connotes exactly as much
support as "extras.ubuntu.com" does.

-- 
Colin Watson   [cjwat...@ubuntu.com]

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Shane Fagan]

On Tue, 2010-11-16 at 11:38 -0800, Rick Spencer wrote:
> Does "/opt/ubuntu/" perhaps suggest a bit of "officialness" or support
> from the Ubuntu community, whereas these apps are specifically *not*
> suppose to have such a connotation? 

Yeah I get what Rick is saying here. Does using /opt/ubuntu imply that
these apps are officially supported in some capacity? I think it does a
little, id say /opt/extra is a better option.

--fagan


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Scott Kitterman]

"Rick Spencer"  wrote:

>On Tue, 2010-11-16 at 15:42 -0500, Scott Kitterman wrote:
>> On Tuesday, November 16, 2010 03:21:46 pm Allison Randal wrote:
>> > On 11/16/2010 12:08 PM, Scott Kitterman wrote:
>> > > IIRC, FHS expects /opt//.  Perhaps Canonical
>should
>> > > register "canonical" if they haven't already and then allocate
>> > > /opt/canonical/quickly or /opt/canonical/arb namespace to this. 
>Given
>> > > the way FHS anticipated /opt to be used, I think Canonical
>(although
>> > > certainly not ideal) may be the best choice.
>> > 
>> > /opt/canonical has a similar problem to /opt/ubuntu, in implying
>> > "officialness" or support from someone (in this case Canonical as a
>> > company, rather than Ubuntu as a community/project/distro).
>> > 
>> > But, there seems to be a fundamental tension here between "official
>> > enough to register with LANANA" and "not too official", so perhaps
>an
>> > added level in the path is the best solution, like
>/opt/ubuntu/extras.
>> > It is specified in the FHS "The structure of the directories below
>> > /opt/ is left up to the packager of the software..." with
>> > /opt// as a suggestion, not a requirement.
>> > 
>> > Allison
>> 
>> I can see that.  I'd strongly prefer it not be something that is
>exactly 
>> Ubuntu.  Even something like ubuntu-arb or ubuntu-appdevel would be
>much 
>> better (apps-on-ubuntu?).
>
>I don't want to go on record contradicting the Tech Board here, but
>"extras" seems to me to fit the bill. I don't think users will be
>exposed to it much, but "extras" seems to imply the kind of "add on"
>behavior that we are going for. Would it be possible to reconsider
>"/opt/extras/"? If not, maybe "/opt/addons-ubuntu" to pick up on
>Scott's
>idea?
>
Much as I'd prefer that, I don't think it's consistent with FHS guidance for 
/opt.  I like extras-ubuntu.  Putting extras first makes it more obvious that 
it's not precisely part of Ubuntu.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Rick Spencer]

On Tue, 2010-11-16 at 15:42 -0500, Scott Kitterman wrote:
> On Tuesday, November 16, 2010 03:21:46 pm Allison Randal wrote:
> > On 11/16/2010 12:08 PM, Scott Kitterman wrote:
> > > IIRC, FHS expects /opt//.  Perhaps Canonical should
> > > register "canonical" if they haven't already and then allocate
> > > /opt/canonical/quickly or /opt/canonical/arb namespace to this.  Given
> > > the way FHS anticipated /opt to be used, I think Canonical (although
> > > certainly not ideal) may be the best choice.
> > 
> > /opt/canonical has a similar problem to /opt/ubuntu, in implying
> > "officialness" or support from someone (in this case Canonical as a
> > company, rather than Ubuntu as a community/project/distro).
> > 
> > But, there seems to be a fundamental tension here between "official
> > enough to register with LANANA" and "not too official", so perhaps an
> > added level in the path is the best solution, like /opt/ubuntu/extras.
> > It is specified in the FHS "The structure of the directories below
> > /opt/ is left up to the packager of the software..." with
> > /opt// as a suggestion, not a requirement.
> > 
> > Allison
> 
> I can see that.  I'd strongly prefer it not be something that is exactly 
> Ubuntu.  Even something like ubuntu-arb or ubuntu-appdevel would be much 
> better (apps-on-ubuntu?).

I don't want to go on record contradicting the Tech Board here, but
"extras" seems to me to fit the bill. I don't think users will be
exposed to it much, but "extras" seems to imply the kind of "add on"
behavior that we are going for. Would it be possible to reconsider
"/opt/extras/"? If not, maybe "/opt/addons-ubuntu" to pick up on Scott's
idea?

Cheers, Rick


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Scott Kitterman]

On Tuesday, November 16, 2010 03:21:46 pm Allison Randal wrote:
> On 11/16/2010 12:08 PM, Scott Kitterman wrote:
> > IIRC, FHS expects /opt//.  Perhaps Canonical should
> > register "canonical" if they haven't already and then allocate
> > /opt/canonical/quickly or /opt/canonical/arb namespace to this.  Given
> > the way FHS anticipated /opt to be used, I think Canonical (although
> > certainly not ideal) may be the best choice.
> 
> /opt/canonical has a similar problem to /opt/ubuntu, in implying
> "officialness" or support from someone (in this case Canonical as a
> company, rather than Ubuntu as a community/project/distro).
> 
> But, there seems to be a fundamental tension here between "official
> enough to register with LANANA" and "not too official", so perhaps an
> added level in the path is the best solution, like /opt/ubuntu/extras.
> It is specified in the FHS "The structure of the directories below
> /opt/ is left up to the packager of the software..." with
> /opt// as a suggestion, not a requirement.
> 
> Allison

I can see that.  I'd strongly prefer it not be something that is exactly 
Ubuntu.  Even something like ubuntu-arb or ubuntu-appdevel would be much 
better (apps-on-ubuntu?).

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Scott Kitterman]

On Tuesday, November 16, 2010 03:32:11 pm Micah Gersten wrote:
> On 11/16/2010 02:21 PM, Allison Randal wrote:
> > On 11/16/2010 12:08 PM, Scott Kitterman wrote:
> >> IIRC, FHS expects /opt//.  Perhaps Canonical should
> >> register "canonical" if they haven't already and then allocate
> >> /opt/canonical/quickly or /opt/canonical/arb namespace to this.  Given
> >> the way FHS anticipated /opt to be used, I think Canonical (although
> >> certainly not ideal) may be the best choice.
> > 
> > /opt/canonical has a similar problem to /opt/ubuntu, in implying
> > "officialness" or support from someone (in this case Canonical as a
> > company, rather than Ubuntu as a community/project/distro).
> > 
> > But, there seems to be a fundamental tension here between "official
> > enough to register with LANANA" and "not too official", so perhaps an
> > added level in the path is the best solution, like /opt/ubuntu/extras.
> > It is specified in the FHS "The structure of the directories below
> > /opt/ is left up to the packager of the software..." with
> > /opt// as a suggestion, not a requirement.
> > 
> > Allison
> 
> I thought that any support for these packages would be coming from
> Canonical and not the community.
> 
> Micah

No.  It's neither.  Support is supposed to come from the application 
developers.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Micah Gersten]

On 11/16/2010 02:21 PM, Allison Randal wrote:
> On 11/16/2010 12:08 PM, Scott Kitterman wrote:
>> IIRC, FHS expects /opt//.  Perhaps Canonical should register
>> "canonical" if they haven't already and then allocate /opt/canonical/quickly
>> or /opt/canonical/arb namespace to this.  Given the way FHS anticipated /opt
>> to be used, I think Canonical (although certainly not ideal) may be the best
>> choice.
> /opt/canonical has a similar problem to /opt/ubuntu, in implying 
> "officialness" or support from someone (in this case Canonical as a 
> company, rather than Ubuntu as a community/project/distro).
>
> But, there seems to be a fundamental tension here between "official 
> enough to register with LANANA" and "not too official", so perhaps an 
> added level in the path is the best solution, like /opt/ubuntu/extras. 
> It is specified in the FHS "The structure of the directories below 
> /opt/ is left up to the packager of the software..." with 
> /opt// as a suggestion, not a requirement.
>
> Allison
I thought that any support for these packages would be coming from
Canonical and not the community.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Allison Randal]

On 11/16/2010 12:08 PM, Scott Kitterman wrote:
> IIRC, FHS expects /opt//.  Perhaps Canonical should register
> "canonical" if they haven't already and then allocate /opt/canonical/quickly
> or /opt/canonical/arb namespace to this.  Given the way FHS anticipated /opt
> to be used, I think Canonical (although certainly not ideal) may be the best
> choice.

/opt/canonical has a similar problem to /opt/ubuntu, in implying 
"officialness" or support from someone (in this case Canonical as a 
company, rather than Ubuntu as a community/project/distro).

But, there seems to be a fundamental tension here between "official 
enough to register with LANANA" and "not too official", so perhaps an 
added level in the path is the best solution, like /opt/ubuntu/extras. 
It is specified in the FHS "The structure of the directories below 
/opt/ is left up to the packager of the software..." with 
/opt// as a suggestion, not a requirement.

Allison

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Scott Kitterman]

On Tuesday, November 16, 2010 03:01:23 pm Allison Randal wrote:
> On 11/16/2010 11:38 AM, Rick Spencer wrote:
> > Does "/opt/ubuntu/" perhaps suggest a bit of "officialness" or support
> > from the Ubuntu community, whereas these apps are specifically *not*
> > suppose to have such a connotation?
> 
> That was mentioned in the meeting. Also the possibility of going with
> simply /opt/, though there is some risk of namespace collision
> there with user-compiled apps.
> 
> Any other suggestions on path names? This is still pretty open, but
> we'll need to lock it down soon, because we're making changes to Quickly
> and other packages for Natty to support whatever install path we choose.
> 
> Allison

IIRC, FHS expects /opt//.  Perhaps Canonical should register 
"canonical" if they haven't already and then allocate /opt/canonical/quickly 
or /opt/canonical/arb namespace to this.  Given the way FHS anticipated /opt 
to be used, I think Canonical (although certainly not ideal) may be the best 
choice.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Allison Randal]

On 11/16/2010 11:38 AM, Rick Spencer wrote:
> Does "/opt/ubuntu/" perhaps suggest a bit of "officialness" or support
> from the Ubuntu community, whereas these apps are specifically *not*
> suppose to have such a connotation?

That was mentioned in the meeting. Also the possibility of going with 
simply /opt/, though there is some risk of namespace collision 
there with user-compiled apps.

Any other suggestions on path names? This is still pretty open, but 
we'll need to lock it down soon, because we're making changes to Quickly 
and other packages for Natty to support whatever install path we choose.

Allison

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Scott Kitterman]

"Rick Spencer"  wrote:

>On Tue, 2010-11-16 at 11:21 -0800, Allison Randal wrote:
>> - They suggested /opt/ubuntu/ instead of
>/opt/extras/ 
>> as the private install location, with the note that (respecting the
>FHS) 
>> we need to register the provider name with LANANA, and "ubuntu" is
>more 
>> sensible in that general context than "extras".
>Does "/opt/ubuntu/" perhaps suggest a bit of "officialness" or support
>from the Ubuntu community, whereas these apps are specifically *not*
>suppose to have such a connotation?
>
Definitely.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Rick Spencer]

On Tue, 2010-11-16 at 11:21 -0800, Allison Randal wrote:
> - They suggested /opt/ubuntu/ instead of /opt/extras/ 
> as the private install location, with the note that (respecting the FHS) 
> we need to register the provider name with LANANA, and "ubuntu" is more 
> sensible in that general context than "extras".
Does "/opt/ubuntu/" perhaps suggest a bit of "officialness" or support
from the Ubuntu community, whereas these apps are specifically *not*
suppose to have such a connotation?

Cheers, Rick


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Allison Randal]

On 11/15/2010 05:53 PM, Allison Randal wrote:
> The fortnightly Tech Board meeting is tomorrow, and the ARB is conscious
> of the fact that we're already a couple weeks out from UDS, and still
> blocking all applications in our queue. So we're submitting this for
> discussion in the meeting, with the understanding that we still have
> details on specific technologies to sort out, which they might request
> to be listed in detail for the next Tech Board meeting, or make a
> general decision and delegate the details to the ARB.

Good initial conversation at the Tech Board meeting this morning, with a 
decision postponed to the next meeting (largely we just ran out of 
time). To summarize:

- Generally in favor of /opt install exceptions where absolutely 
necessary (not formally approved yet).

- Some pushback on allowing Python applications and their 
application-specific libraries to install outside /opt. They're willing 
to skip generating .pyc files and Python version symlinks (just for 
Maverick), if it means we can install in /opt. We have a workaround that 
may allow us to get by in Maverick without this exception.

- They suggested /opt/ubuntu/ instead of /opt/extras/ 
as the private install location, with the note that (respecting the FHS) 
we need to register the provider name with LANANA, and "ubuntu" is more 
sensible in that general context than "extras".

Allison

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Allison Randal]

On 11/15/2010 02:36 PM, Barry Warsaw wrote:
> On Nov 15, 2010, at 05:27 PM, Scott Kitterman wrote:
>
>> Unless there is some commitment to API stability, this is actively harmful.
>> If you are writing functions to be consumed generally, and not just within
>> your program/module/whatever, then you have to take on some additional
>> responsiblities.  If you don't, then whoever tries to take advantage of your
>> code is in for a world of hurt.

It's safe to assume that these lightweight apps aren't intended to be 
used as general-purpose libraries. In fact, it's a requirement of the 
ARB process, as libraries are automatically "promoted" to a full REVU 
process. I see potential for libraries to start as application-specific 
through the ARB, and then grow into something general-purpose that goes 
to REVU.

> Sure, but this is the "consenting adults" argument.  The thing is, the
> packages are going to be available in either case, so you're just putting an
> inconvenient sys.path hack in front of anyone who really wants to do it.

The tricky thing is, we're wrapping lightweight apps in an inconvenient 
sys.path hack (to make it difficult to get to application-specific 
libraries, for security and isolation) AND trying to make it easy for 
new developers at the same time. The tools just aren't up to the job yet.


The fortnightly Tech Board meeting is tomorrow, and the ARB is conscious 
of the fact that we're already a couple weeks out from UDS, and still 
blocking all applications in our queue. So we're submitting this for 
discussion in the meeting, with the understanding that we still have 
details on specific technologies to sort out, which they might request 
to be listed in detail for the next Tech Board meeting, or make a 
general decision and delegate the details to the ARB.

Allison

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Rick Spencer]

On Mon, 2010-11-15 at 17:36 -0500, Barry Warsaw wrote:
> On Nov 15, 2010, at 05:27 PM, Scott Kitterman wrote:
> 
> >Unless there is some commitment to API stability, this is actively harmful.  
> >If you are writing functions to be consumed generally, and not just within 
> >your program/module/whatever, then you have to take on some additional 
> >responsiblities.  If you don't, then whoever tries to take advantage of your 
> >code is in for a world of hurt.
> 
> Sure, but this is the "consenting adults" argument.  The thing is, the
> packages are going to be available in either case, so you're just putting an
> inconvenient sys.path hack in front of anyone who really wants to do it.

I write apps and libraries as very distinct activities. As an app
developer, my supporting libraries tend to be extremely specific to my
app in design and functionality, with no thought to external consumers
of those libraries. I also do not test any scenarios outside the scope
of my app. If I want to write a library for someone else to use, I
design for that purpose. So, as a user (as in a user of the app review
board) I would just as soon not to have the additional concern of making
my supporting libraries also have to be usable by other developers.

Cheers, Rick


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Barry Warsaw]

On Nov 15, 2010, at 05:27 PM, Scott Kitterman wrote:

>Unless there is some commitment to API stability, this is actively harmful.  
>If you are writing functions to be consumed generally, and not just within 
>your program/module/whatever, then you have to take on some additional 
>responsiblities.  If you don't, then whoever tries to take advantage of your 
>code is in for a world of hurt.

Sure, but this is the "consenting adults" argument.  The thing is, the
packages are going to be available in either case, so you're just putting an
inconvenient sys.path hack in front of anyone who really wants to do it.

-Barry


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Scott Kitterman]

On Monday, November 15, 2010 10:17:01 am Barry Warsaw wrote:
> On Nov 15, 2010, at 12:06 PM, Stefano Rivera wrote:
> >Why not just use python-support/dh_python2's private-module mode? This
> >is what most applications should be using, anyway, rather than polluting
> >the public Python module namespace.
> 
> I hesitate to mention this here because I agree that in this context,
> application-private modules makes good sense.
> 
> In *general* though, I'm not a big fan of it because properly organized and
> named packages should not be "polluting" but enhancing the public
> namespace. A good way to think about it is that an "application" (i.e. the
> command you execute) is just the tip of the iceberg on top of a rich
> library that could be useful to others.  I'm thinking about examples like
> 'bzr' and 'bzrlib' which were explicitly designed to work that way, to
> great benefit.

Unless there is some commitment to API stability, this is actively harmful.  
If you are writing functions to be consumed generally, and not just within 
your program/module/whatever, then you have to take on some additional 
responsiblities.  If you don't, then whoever tries to take advantage of your 
code is in for a world of hurt.

As you say, when it's design for it, this is great, but not for general 
application code.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Scott Kitterman]

"Allison Randal"  wrote:

>On 11/11/2010 07:52 AM, Scott Kitterman wrote:
>>
>> I wasn't in all the the ARB related sessions, so perhaps this got
>rediscussed
>> in a session I didn't attend, but my recollection was that the idea
>for
>> Maverick was to put everything in /opt except for things like
>.desktop files
>> that need to be in the user's path to work and to drop those into an
>extras
>> specific location that would be in the user's path, but not the
>system path.
>
>Yes, that's what this proposal is saying, though in more detail. 
>Specifically, apps can only install outside /opt when it's impossible
>to 
>install or run in /opt with current technology, and are expected to 
>either install in a custom path (named extras) or to modify the
>filename 
>(with extras) so the files for the app don't pollute the general 
>namespace. We can't have them install outside the system path, though, 
>because the precise problem with these files is that they can't install
>
>or run outside the standard system paths.
>
>I'll edit a bit to make those points clearer in the draft.
>
I will confess to a bit of frustration at this point.

I feel like we've had a couple of rounds of discussion where some consensus was 
reached only to be offset later by "Oops. Too hard.".

I think it's clear the ARB is going to go ahead with something for Maverick, so 
rather than continue to discuss what ought to be for Maverick, I think you 
ought to announce what you are doing based on what's doable and what additional 
reviews you are doing to offset associated risks.

I suspect doable is a regular package plus detailed code review.

My view is that this is not enough of an incremental improvement in timely 
delivery to make a significant difference to application developers and the 
resources that might go onto ARB reviews would be better utilized making the 
tools better to make the process faster and lighter for Natty (recognizing that 
these aren't necessarily fungible).

We are only going to get a few shots at convincing application developers that 
delivering on top of Ubuntu is easy and fast.  If it's not easy and fast, 
credibility of future improvements will be hurt.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Stefano Rivera]

Hi Barry (2010.11.15_17:17:01_+0200)
> A good way to think about it is that an "application" (i.e. the command you
> execute) is just the tip of the iceberg on top of a rich library that could be
> useful to others.  I'm thinking about examples like 'bzr' and 'bzrlib' which
> were explicitly designed to work that way, to great benefit.

I agree with applications that have an API that's designed to be
consumed by others. Of course that requires a little more generalisation
in the design. Not *all* applications should have private modules, and
you shouldn't have to hack sys.path to get access to a library you need,
but most apps have no need to put themselves in the public namespace.
Especially the kind of apps that ARB is intending to distribute.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Allison Randal]

On 11/11/2010 07:52 AM, Scott Kitterman wrote:
>
> I wasn't in all the the ARB related sessions, so perhaps this got rediscussed
> in a session I didn't attend, but my recollection was that the idea for
> Maverick was to put everything in /opt except for things like .desktop files
> that need to be in the user's path to work and to drop those into an extras
> specific location that would be in the user's path, but not the system path.

Yes, that's what this proposal is saying, though in more detail. 
Specifically, apps can only install outside /opt when it's impossible to 
install or run in /opt with current technology, and are expected to 
either install in a custom path (named extras) or to modify the filename 
(with extras) so the files for the app don't pollute the general 
namespace. We can't have them install outside the system path, though, 
because the precise problem with these files is that they can't install 
or run outside the standard system paths.

I'll edit a bit to make those points clearer in the draft.

Allison

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Barry Warsaw]

On Nov 15, 2010, at 12:06 PM, Stefano Rivera wrote:

>Why not just use python-support/dh_python2's private-module mode? This
>is what most applications should be using, anyway, rather than polluting
>the public Python module namespace.

I hesitate to mention this here because I agree that in this context,
application-private modules makes good sense.

In *general* though, I'm not a big fan of it because properly organized and
named packages should not be "polluting" but enhancing the public namespace.
A good way to think about it is that an "application" (i.e. the command you
execute) is just the tip of the iceberg on top of a rich library that could be
useful to others.  I'm thinking about examples like 'bzr' and 'bzrlib' which
were explicitly designed to work that way, to great benefit.

-Barry


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Stefano Rivera]

Hi Allison (2010.11.11_04:25:40_+0200)
> Let us know of any changes (anything I missed, or that doesn't seem to
> accurately reflect the discussions). We'll try to finalize it next week.

Hi, some Python-related questions:

> * There is no support in Quickly, python-distutils-extra,
>   python-distutils, and python-support for installing Python binaries
>   and libraries in /opt.

Why not just use python-support/dh_python2's private-module mode? This
is what most applications should be using, anyway, rather than polluting
the public Python module namespace.

I mean --install-lib=/opt/extras/$packagename, and then tell
pysupport/dh_python2 to look for modules there.

This does mean that the package will automatically install a
/usr/share/python-support/$packagename.private, or
/usr/share/python/runtime.d/$packagename.rtupdate for dh_python2.

While this is outside /opt, it shouldn't result in clashes, as package
names have to be unique, anyway.

Doing this will result in byte-compiling on install, and
re-byte-compiling when the system default Python version changes. It
only supports .pyc files for one python version at a time, but for
applications (as opposed to libraries) this is all that is required.

> To increase the separation of extras from regular applications, files
> installed outside /opt will be required to either prepend "extras" to
> their name (e.g. "extras-.desktop"), or to add "extras" to
> their path (e.g. "/usr/lib/python2.6/extras/...").

I don't see why ARB packages should be installing modules into the
public python namespace, even withinin an "extras" module. ARB is
supposed to be for applications, not libraries, right?

> Quickly will include a python_path to work with Python libraries
> installed in /opt/extras/lib.

Why is that necessary, shouldn't ARB packages be self-contained?

> Quickly will automatically perform name-mangling on .desktop and panel
> files after Natty, until system packages support these files living in
> /opt.

Can we go one step further and automatically generate the
software-centre metadata for the binary control file, from the installed
.desktop file (assuming only one). This looks like something that could
be done by pkgbinarymangler.


I packaged up a pyweek game for ARB [1] and noticed a couple of other
things installed outside /opt that don't seem to be covered by
exceptions:
/usr/share/doc/$packagename
/usr/share/lintian/overrides/$packagename

[1]: https://launchpad.net/bugs/675033


Not a serious issue, but what about icons? With an absolute filename for
the icon, the application either can only install a 48x48 icon or an
svg, rather than taking advantage of the hicolor theme.


I noticed a couple of issues with the ARB documentation. It's unclear
about whether the application is filed on a wiki page with an-email to
the ARB list or as a bug. Can this be cleared up?

Other minor bits I'll fix / improve myself:
* Lack of dh7 examples,
* The deprecated XB-Ppython-Version appearing in examples

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Scott Kitterman]

On Wednesday, November 10, 2010 09:25:40 pm Allison Randal wrote:
> I've drafted a proposal for the Tech Board based on our discussions at
> UDS and on ubuntu-devel. The ARB is still reviewing it, but we'd also
> like to open it up for broader review:
> 
> https://wiki.ubuntu.com/PostReleaseApps/MaverickExceptionsProposal
> 
> Let us know of any changes (anything I missed, or that doesn't seem to
> accurately reflect the discussions). We'll try to finalize it next week.

I wasn't in all the the ARB related sessions, so perhaps this got rediscussed 
in a session I didn't attend, but my recollection was that the idea for 
Maverick was to put everything in /opt except for things like .desktop files 
that need to be in the user's path to work and to drop those into an extras 
specific location that would be in the user's path, but not the system path.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Paul Sladen]

On Wed, 10 Nov 2010, Allison Randal wrote:
> https://wiki.ubuntu.com/PostReleaseApps/MaverickExceptionsProposal

My recollection of the session was /if/ normal levels of package
oversight can be offered during the natty cycle then the
"/opt exception" would be fine.

(Conversely, if oversight can't be provided in the interim,
short-cutting the system quality via the ARB process is not ideal).

> We'll try to finalize it next week.

Would it be worth simplifying the extras .desktop location to simply
be a "chroot" under /opt:

  [/opt]/usr/share/applications/*.desktop

(and dittos for the rest), this would then be closer to what the
regular packaging tools expect and make it easier to convert back and
forth?

-Paul
-- 
Berlin, DE


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Allison Randal]

I've drafted a proposal for the Tech Board based on our discussions at
UDS and on ubuntu-devel. The ARB is still reviewing it, but we'd also 
like to open it up for broader review:

https://wiki.ubuntu.com/PostReleaseApps/MaverickExceptionsProposal

Let us know of any changes (anything I missed, or that doesn't seem to
accurately reflect the discussions). We'll try to finalize it next week.

Thanks!
Allison

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Allison Randal]

On 28/10/10 21:55, Steve Langasek wrote:
> On Mon, Oct 25, 2010 at 10:54:15PM -0400, Allison Randal wrote:
>> - develop checks (and tools for automated checking) between apps that
>> install any files outside /opt and main|universe|restricted|multiverse
> 
> I assume there's a missing "conflicts" in the above?

Aye.

> ObPedantic: /opt is specified in the FHS, so *all* apps are required to
> respect the FHS. :)

:) True, largely because the FHS is more relaxed about subdirectories
under /opt, as in: "The structure of the directories below
/opt/ is left up to the packager of the software".

It's still better if apps follow the naming conventions of the rest of
the FHS, even under their own subdirectories in /opt (libs in
/opt/.../lib, images in /opt/.../share, etc.) but if they mix it up, or
just dump all their files in one directory, at least it's one directory
off to the side in /opt.

Allison

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: continuing conversation from UDS-N - Application Review Board

[Steve Langasek]

On Mon, Oct 25, 2010 at 10:54:15PM -0400, Allison Randal wrote:
> - develop checks (and tools for automated checking) between apps that
> install any files outside /opt and main|universe|restricted|multiverse

I assume there's a missing "conflicts" in the above?

> >- How stringent should we be about FHS? For example, are images 
> > installed in /usr/lib an automatic rejection?

> This is one of the things that the /opt install solves. It's not such a
> big deal if an app installs images in (for example)
> /opt/extras/myappname/lib as it is to pollute the global lib paths. FHS
> is also a good area for encouraging developers to a better way.

> Apps that install outside /opt will be required to respect the FHS.

ObPedantic: /opt is specified in the FHS, so *all* apps are required to
respect the FHS. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel