Re: Questions

On 16 January 2012 23:50, Dave Abrahams <dave@...> wrote:
>
> on Mon Jan 16 2012, Thomas Leonard <talex5-AT-gmail.com> wrote:
>
>> On 16 January 2012 20:00, Dave Abrahams <dave@...> wrote:
>>>
>>> I am investigating 0install both as a new user and as a potential
>>> "exploiter" for a project I've been working on called "ryppl" (I'll
>>> explain more about that later).  I have several questions:
>>>
>>> * I installed 0install through macports.  The latest version there is
>>>  version 1.2.  I don't know how to upgrade 0install itself in that
>>>  situation.  How do I do that?
>>
>> I guess you need to wait for MacPorts to update it.
>
> what about using, e.g. pip or easy_install?

As I understand it, the main problem is the non-Python dependencies (PyGTK, etc).

> And, stepping back, isn't there something fundamentally wrong with a
> packaging system that can't update itself?

On Linux systems, it's expected that programs don't update themselves. Other systems may have other conventions, though. The Windows version updates itself.

>> You can do:
>>
>> 0install update alias:foo
>
> Nifty; but that's no in the 0install man page I have.

Fixed.

> Anyway, why should I have to write alias: ?  I understand that if
> there's an ambiguity you have to tell people about it and stop, but 99%
> of the time there's none.

It could cause a problem with scripts (e.g. a script that did "0launch selections" might suddenly fail if the user happened to have an alias called "selections"). Arguably scripts should always use a prefix (e.g. "0launch file:selections"), but relative paths weren't supported with file: before (now fixed).

> Ease-of-use is really important to me.  Ryppl's primary test case is
> going to be the Boost C++ Libraries, which do *not* have a good
> ease-of-installation story.  It's part of our mission to fix that.
>
>>>  I'd also like to be able to bless some "feed catalogs" that map short
>>>  names to feeds and be able to install anything in one of those
>>>  catalogs by its short name (unless there was an ambiguity).  I can
>>>  always put a wrapper around 0install for this sort of thing, but I
>>>  worry that if it isn't a native feature 0install will not be able to
>>>  gain much market share.
>>
>> ROX has a feed catalog like that ("ROX-Defauts", which sets up a "rox"
>> alias and maps various MIME types to ROX application handlers).
>
> I'm not sure if that's what I mean by a feed catalog.  I'm thinking of
> something like
>
>  http://roscidus.com/0mirror/feed-list
>
> [BTW, what do the initial "-" characters mean on some of those feeds?]

Retired (no longer monitored for updates, usually because they no longer exist, but still available from the mirror).

> but with an optional second column that gives a short name for each feed
> (where the default short name is the last part of the URI, but without
> the .xml extension).  So if I said http://roscidus.com/0mirror/feed-list
> is a "blessed feed catalog" then I could "0install TightVNC" and it
> would be the same as "0install http://0install.de/feeds/TightVNC.xml".

With the ROX-style system, you can just type "TightVNC" and it will download it automatically the first time you use it.

>> A more general one would indeed be useful.
>>
>>> * Even if you don't make short names available, doesn't it make sense to
>>>  give the feed URL when announcing an update?  I ask in part because of
>>>  http://article.gmane.org/gmane.comp.file-systems.zero-install.devel/4811
>>>  and the feeling that I must be missing something obvious.
>>
>> Oops. Cut-and-paste problem; the page with the feed link has moved to:
>>
>>   http://0install.net/packaging-binaries.html
>
> Sorry, what I mean is that I was expecting to see this URI in the posting:
>
>  http://0install.net/2007/interfaces/0publish-gui.xml

Could do. Especially now we have the "0install update" command.

>>> * Is there any chance that 0install could be dual-licensed so it was
>>>  available under some FOSS license that doesn't include the letters
>>>  "GPL?"  I know, I know, but unfortunately it is a reality that even
>>>  LGPL is enough to prevent adoption in some shops.
>>
>> Unlikely. Probably easier to educate them that LGPL isn't going to be
>> a problem (unless the company actually wants to make a competing,
>> non-LGPL installer using our code and can't work out how to do it as a
>> separate module). Normally, of course, they won't be distributing
>> 0install itself at all and so there's no problem with copyright
>> anyway.
>
> As I said, "I know, I know, but..."
>
> Of course it's probably easier for _you_ if _I_ educate them about LGPL
> ;-).

We could perhaps put something about it on the legal issues page (e.g. "Since you're not distributing 0install itself, you don't need a license to distribute it, and can therefore ignore the license terms entirely; your users can use a client with any license they please as long as it understands the XML format."). Though it would need more detail for people bundling it (0export, etc).

--
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel