248359 - Show and link to dependencies

Status: RESOLVED DUPLICATE of bug 592517

(addons.mozilla.org Graveyard :: Public Pages, enhancement, P5)

Description

[alanjstr]

Some extensions rely on JSLib or EnigMIME to be installed.  If people are like
me, they won't realize this even if it says it in the description.  The database
should have a table that has columns for ID and Dependency ID.  If we can get
the JSLib people on board, then I think we should have a rule that an extension
can't be added if the dependencies aren't already there.  Even better would be
if the install.rdf has the GUID of any dependencies it requires!  If someone
downloaded Moji from its homepage, Extension Manager would realize that there
were dependencies and offer to retrieve them.

Comment 1

[Wolf [:wolf]]

From the Extension Packaging documentation:
em:requires
    A object specifying another extension that is required by this extension.
em:id specifies the GUID of the extension that is required, em:minVersion
specifies the minimum required version and em:maxVersion - much as for
em:targetApplication. An Extension's manifest can specify 0 or more of these
em:requires objects.

  <em:requires>
    <Description>
      <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
      <em:minVersion>0.7</em:minVersion>
      <em:maxVersion>1.2</em:maxVersion>
    </Description>
  </em:requires>

Note: This field does not do anything in Firefox 0.9 but will in the future be
used to disable chains of incompatible extensions. Please begin using it now.

Comment 2

[alanjstr]

Ok, so what we really need is for this code to be turned on in 0.9 ... oh, wait :-D

Comment 3

[Brian King [:kinger]]

You can count the jslibfolks in.

The first step we are curently working on is making jslib compatible with EM:

http://bugzilla.mozdev.org/show_bug.cgi?id=6758

Comment 4

[Fabian Rodriguez:MagicFab]

Brian: wrong bug # ?

Regarding Thunderbird (since someone mentioned Enigmail), is there any
indication/ mechanism in the GUI to suggest (require) installation of required
extensions such as Enigmime ? What about automatic removal and update of
existing dependencies ?

IMO this should be considered MAJOR as it can break existing working
installations  and prevent new ones from completing succesfully. It should also
be changed to OS: All, Hardware: All .

I found the mentioned specs here:
http://www.bengoodger.com/software/mb/extensions/packaging/extensions.html

Comment 5

[alanjstr]

Fabian -

Brian is talking about JSLib, for which he is a developer.  As for automatic
downloading and upgrading, that's an entirely different bug that belongs to the
Extension Manager component.  This bug is only about the website which is not a
major bug.

Comment 6

[Wolf [:wolf]]

Does Firefox 1.0 support em:requires yet? 

Dumping to nobody for after-1.0 stuff.

Comment 7

[Wolf [:wolf]]

Bulk Moving Web Site bugs to new component.
(Filter: massumowebsitespam)

Comment 8

[alanjstr]

Have we established the syntax for install.rdf for dependencies?  Can someone
paste an example or a bug?

Comment 9

[Paul Tomlin]

Attachment: partial patch to store and display dependencies

Not intended for commit just a review, is it going the right way.

This works for creating a dependency between a particular version of an addon
and another addon (but not a particular version). That little issue is because
the AddOn class doesn't have code to represent a specific version, just the
'current' one. No biggy.

Once I/we patch AddOn to handle representing a specific vID then we'll be able
to point dependencies at specific versions too.

No code currently in CVS for submission of XPI's so I can't patch in a
dependency parser (based on the example given in comment #1).

There's no schema in CVS to patch...

CREATE TABLE `dependency` (
  `vID` int(11) NOT NULL,
  `dID` int(11) NOT NULL,
  PRIMARY KEY(`vID`, `dID`),
  KEY `vID` (`vID`),
  KEY `dID` (`dID`)
) TYPE=InnoDB PACK_KEYS=0;


ALTER TABLE `dependency`
  ADD CONSTRAINT FOREIGN KEY (`vID`) REFERENCES `version` (`vID`) ON DELETE
CASCADE ON UPDATE CASCADE,
  ADD CONSTRAINT FOREIGN KEY (`dID`) REFERENCES `version` (`ID`) ON DELETE
RESTRICT ON UPDATE CASCADE;

Comment 10

[alanjstr]

Bug 298497 has landed.  
http://wiki.mozilla.org/Extension_Manager:Extension_Dependencies

We'll need to make sure that the updateURL is not present and that we already have the em:id in the DB.  

1) Do we want to store the dependency info?  
It would have to be at the version level.  The application supports a range, min and max, for the dependency, so I suggest we store only the ID and let the application deal with the range

2) Do we require the dependency to be on AMO?  I'd say that's a policy issue, but I am leaning heavily towards yes.  We don't want someone having a shell extension that forces the user to load something off-site.

3) What happens if the dependency hasn't been approved yet?

4) What if the dependency is some extension that is only a library of functions, like an extended jslib?  How do we test jslib?

Comment 11

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Comment on attachment 199026 [details] [diff] [review]
partial patch to store and display dependencies

UMO v2 is live.  I had a lot less to do with its development, so check with morgamic before using me for reviews.

Comment 12

[Cameron]

AMO bugspam. Correcting QA contacts on OLD bugs ([e-mail])

-> Correct QA contact ([e-mail])

Filtermeplzkthx

Comment 13

[Justin Scott [:fligtar]]

Attachment: mockup, v1

This mockup shows the placement of a required add-on on the details page.

Comment 14

[Wil Clouser [:clouserw]]

Forward duping this to the new implementation bug